Matthew Chestnut is a Senior Consultant at ThreeWill. He has over 25 years of software development experience around enterprise and departmental business productivity applications. He has a proven track record of quality software development, on-budget project management and management of successful software development teams.
Danny serves as Vice President of Client Development at ThreeWill. His primary responsibilities are to make sure that we are building partnerships with the right clients and getting out the message about how we can help clients.
Find this Podcast “What is Sustainment?” on the ThreeWill Soundcloud, Stitcher, and iTunes.
Transcript
| Danny: | Hello and welcome to The ThreeWill Podcast. Today I’ve got Matthew Chestnut here with me. Thank you for joining me Matthew.
|
| Matthew: | Hello Danny.
|
| Danny: | How are you doing?
|
| Matthew: | Doing well. This is our second or third time we’ve gotten together. I can’t remember exactly how much fun we’ve had in the past but here we go again.
|
| Danny: | We’ve had a lot of fun. It has been fun. It’s good for me to check in on you every once in a while. Matthew is across the wall from me here, if he’s having a bad day I know because he’s kicking the wall and he’s abusing it. No, I never hear you kick the wall. You don’t get mad. I don’t think I’ve seen you get mad.
|
| Matthew: | I can tell when Danny’s busy doing his work because I hear a low rumbling from the office. It’s just a series of continual phone calls, I can tell Danny’s busy doing stuff.
|
| Danny: | Doing something, something in there, he’s doing something. What I’d like to talk to you today is about a couple of things. One is, I know you’ve done a lot of work with what we call sustainment. I’d like to start off with that, and then I’d like to talk a little bit about when you’re working with people all over the world, with offshore partners, with people in various locations, maybe some of the things you picked up in on that projects.
|
| Matthew: | Sure.
|
| Danny: | Just starting off with sustainment, tell me for folks who may not know what it is, what is sustainment?
|
| Matthew: | In ThreeWill world sustainment is an outcropping and offshoot of work we did for a major company, where they did not want us to just dump this particular product on their support team and have them support it. It really worked out to be a great thing, they asked us if we would put together a 1 year, 2 year, 3 year plan to support them in this particular product, so that if questions arose or new features needed to be added we would be ready to do so. It spawned this whole new ecosystem within ThreeWill where we now offer that as a standard offering for our enterprise customers, as an option, it’s certainly not required.
|
| The idea behind sustainment is you’ll be guaranteed that you will get our attention. Obviously if you’re a customer we certainly want to pay attention to you, but if you’ve purchased a sustainment agreement you certainly will go to the top of the queue if you have any issues that arise.
| |
| Danny: | That’s great. You have a certain number of hours that you’ll have committed towards to the years that the way that it’s all set up.
|
| Matthew: | It works a lot like a lawyer and a retainer fee in many ways. Now, we don’t hold on to your money, if you don’t use it no big deal, it usually rolls over to the subsequent year, which is great. But it gives our customer the peace of mind knowing that if things come up during the year, that may not be big items but they’re certainly something that affects the production or affect the use, that they can get those issues resolved without having to go through a budgeting or bidding or any process like that. They just call us and we get it taken care of.
|
| Danny: | This is things like level 3 support, is it building new features in [crosstalk 00:02:56]
|
| Matthew: | I wish it were level 3 support, sometimes it’s level 1 support, which we don’t mind. Just like anything else, if you develop an application for someone you’re name or your company gets associated with that, so if there’s a problem with X they call Matthew. It’s not because there’s a problem with the program necessarily, but it is associated with it. We sometime will triage, which we certainly don’t mind. In fact we’d rather them call us than them be frustrated trying to figure out who to call within their organizations. Sometimes we deal with some really, really big companies and they’ve got such a diverse set of products on their infrastructure, the people working in IT don’t know who to route these people to. We can help with that.
|
| Danny: | That’s great. Can you use these hours to perhaps build in new features.
|
| Matthew: | Certainly, yeah. We’re not just sitting around waiting for bug fixes. A lot of times we can work with a customer who’s got a set of features that might be small in nature, or they might be large. It’s really just trading dollars for dollars. It’s just a bucket of pre-allocated money that they know that they have. If they don’t use it it gets to roll over. But a lot of times we find is that towards the end of the year, end of the budget year, the customer will say, “Hey I’ve got this bucket of money, and I’ve got these things that have been building up, these feature requests et cetera. Let’s go ahead and get these take care of,” and that’s what they’ll do.
|
| Danny: | Awesome. As you’re looking at this, Tommy and I have been talking a lot about process lately, and knowing that we use Scrum internally how does this all fit with getting the request from a client? How does that work?
|
| Matthew: | Yeah, it really works as little mini projects. The mini project may be as simple as a question and an answer. What we’ll do is the question will come in, either via phone, email, directly to our personal email, or to sustainment@threewill, we have a email address that the customers can use. Regardless of how we get it we’ll create a ticket inside of our ticketing system. The idea behind capturing this information in a ticket is invariably we have other things that need to be attached to this ticker. Whether I’m talking with a colleague, there’s time involved, what have you, conversations. We always want to be able to go back to an audit trail if you will of when the customer called, what they called about, did we resolve it, how fast we resolved it, et cetera. It depends on the scope of the question.
|
| If it’s small in nature, where it’s a quick answer, we get it done in 15 minutes no big deal. If it’s something that takes a little bit of research we might call the customer back within that day or maybe the next day. But if it’s a series of things that they want done, new feature request, et cetera, we will usually provide the customer with an estimate. We use our standard sizing spreadsheet. We call it the t-shirt sizing, small, medium and large, just to give the customer and idea of what the estimate in effort, which turns to dollars, would be for a given set of features that they’re asking for.
| |
| Danny: | Is that what Bruce uses for creating a product backlog or is that more lightweight.
|
| Matthew: | It’s much more lightweight. We realized that the sustainment items that come up, we don’t want to overdo it with heavy project management because that doesn’t do anybody any good. We spend too many cycles for something very small. But we realize we need to be able to give the customer an idea, what’s it going to cost him in time and effort. We needed to do that quickly. This t-shirt sizing really is a great way to do it. We’ll think, as a developer we’ll say, “Okay, I think this is going to take me an hour or 2,” or, “It might take me half day,” or, “It might take me 3 days.” Based on that we simply plug it into a spreadsheet, or we just look at a chart, and it translates 3 hours of development time equals 6 hours of development time, QA, user acceptance testing and deploy to production. There’s all these layers that get added on. If it takes me 15 minutes to do, great, but we have processes we have to follow to get it into production and we have to account for that as well.
|
| Danny: | That’s great. Just earlier today I had a request from a prospect asking about, it was basically some customizations to the things that we Trove, with the Microsoft 365 and Salesforce integration.
|
| Matthew: | Salesforce, yes.
|
| Danny: | They were asking for sort of a lightweight, “How much does it cost to do this, this and this?” It wasn’t something I needed a full product backlog around. I forwarded it on to Bruce and to Eric and said, “Hey, can you t-shirt size these.” The size are extra small, is it’s less than $1,000. Small is it’s less than 5,000. Basically gave them some buckets to fill them with. I’d be interested to see what you guys to see if we could use that for when those types of requests come in.
|
| Matthew: | What’s important, and we probably wouldn’t do that necessarily for a new customer or an application we’ve never dealt with before because there’s too many unknowns. But for a product that we originally developed or we’ve picked up and started supporting, so we’re familiar with it and we’re talking to the subject matter experts who have dealt with it before, we can get a pretty good idea how much effort it’s going to take. Sometimes we also balance it based on the resources going to be doing it. For example if I’m the world’s greatest person at digging holes and I’ve only got so many holes I can dig and we’ve got to get somebody else to do it, they might not be as fast at doing that, so we adjust the estimates accordingly.
|
| Danny: | That’s great. That’s great. Let’s switch over to the second subject that I would like to talk about, which is on some of your projects you’re working with teams that are really spread across the world. What’s the challenges that come to play with doing that? What are some of the things that you’ve learned when working with teams that are really distributed everywhere?
|
| Matthew: | It’s interesting, even with a team size of you plus 1, communication is very important. Even in our sustainment world we’re always trying to document. Not crazy documentation where we’re writing novels and books about a certain process, but facts that help us in the future. We just had a scenario yesterday where we had to figure out why we did something back in June of last year. We went back to the history and we found it.
|
| When we’re talking about a geographically distributed team, we use our standard technique of stand up meetings. When we’re doing a project type work, where we have our daily stand ups, 15 minutes, tell me what you did yesterday, tell me what you’re going to do today, tell me what is blocking you if anything. Those are invaluable, because it keeps the finger on the pulse of the project for all involved. It’s important I think for everyone involved in the project, even if you’re not working on a certain area to know if a area’s going well or not. Certainly as a project manager you must know that.
| |
| We use a variety of tools. We use our own SharePoint Microsoft 365 instances. We have a project extranet that has lists for issues, lists for backlog items, sprints, et cetera. We’ve also used commercial applications, some of our customers deal with Atlassian and Jive for example and we’ve used that to manage issues, track them, et cetera. The idea here is you need to keep track of your backlog items for the project, you need to keep track of your print items for the given sprint that you’re working on, whether it’s a 1 week sprint, 2 week sprint, 3 week sprint. You need to know what those tasks are, because that’s what you’re going to be reporting on in a daily basis, how are you progressing against those items you’ve committed to complete by the end of the sprint.
| |
| Danny: | What are your … I guess for some of the recent projects you’ve been on, what, is it a 2 week sprint? What’s a typical sprint for you [crosstalk]?
|
| Matthew: | It’s interesting, the project I’m currently is kind of in a strange phase where we did a lot of work and we were doing 2 week sprints at the time. Now we’ve gotten to a certain point where we’re transitioning it into a production environment. We’re resolving any issues that arise, not necessarily with our application but issues with the environment, what is blocking us from getting this thing deployed to production. There’s lots of little things that we’re discovering in this website. It’s static content that we never knew existed on the website, it’s processes on all these other machines that might be SQL server agents that are running every day to transfer information from one enterprise Oracle database to a SQL server database.
|
| It’s more like, this thing, this website hasn’t changed in years, and we’re discovering more and more about it as we get closer and closer to the production deadline. We’re really triaging issues that come up, the customer helps us prioritize them if they’re important to get resolved before we got to production, they’re marked high or higher, high, critical or blocker, and we address those as quickly as possible. Then we let things settle down. In this particular situation we’re dealing with about 20 items that are in this state of, we’ve got to get these things done. We get it down to maybe 15 and then it bumps back up to 22, and then we get it back down to 20.
| |
| But it’s not program stuff, it’s not stuff that we did necessarily but it’s stuff we’re finding about the project, about the implementation that we never knew about because the people who implemented it years ago are long gone. We’re uncovering archaeological artifacts as we go on. That’s where having good communication, having the proper issue list, dealing with a world wide team, we’ve got group doing load testing, QA all around the US and even around the world. Just coordinating those efforts is an important aspect of successfully delivering a project like that.
| |
| Danny: | Great. It almost sounds like you’re … Some projects have a deployment sprint or deployment set of sprints.
|
| Matthew: | They have an infrastructure, which is really good, where we’ve got a sandbox environment where we can do with it what we want, a QA environment that we share for deploying into and doing strict QA testing and then a brand new production environment that ultimately this application will reside in. They’ve got their existing production environment that we don’t have to touch. We’ve got all the infrastructure we need to do the testing, we’re just trying to make certain that the new production has all the functionality of the existing production, and that’s the trick.
|
| Danny: | Any other tips or pointers when you’re working with a team that’s distributed across the world?
|
| Matthew: | It’s interesting, just be aware of timezone difference. Sometimes when you have those meetings at 6:00am in the morning it’s not fun. For them it’s not having a meeting at 10:00pm at night either. Just be aware of cultural differences too, be certain you are clear on your communication. If you’ve got a 12 hour, or even a 24 hours turn around on a communication you send, make certain that you send it and it’s very clear. You don’t want to get this back and forth because the latency will just kill you if you’re taking 3 or 4 days to finally get to the real question, where if you just spend a little bit of time at the outset, crafted your communication, your email properly, you could have gotten your question answered much sooner.
|
| Danny: | Do you do screen sharing? What’s been some of the … You mentioned some of the tools that you use which are like your SharePoint client side and those type of things. What are you using to maybe get everybody on the same page?
|
| Matthew: | Quite frankly having a common QA environment, and having a methodology that we use to deploy to those environment, makes it easy for us to replicate the problem. Since we’re on a shared environment if they say there’s a problem happening with this set of steps they followed, typically we can reproduce it. That’s hugely helpful. If we were on 2 different systems, that might be harder to do, but because we’re on a shared environment that makes it much easier.
|
| Danny: | Awesome, yeah. Thank you so much for taking the time to do this. I appreciate our little cordially get-together. It’s always nice …
|
| Matthew: | Yeah, I look forward to the next one.
|
| Danny: | It’s always nice to pull you out of the room and say, “Come into my office Matthew, come hang out with me for a little while.” I appreciate your time.
|
| Matthew: | You’re quite welcome Danny.
|
| Danny: | Thank you for all that you do. It’s incredible what you guys are doing with regards to sustainment, with regards to the stuff that you’re doing on the large project that you’re on right now. We feel so lucky to have you as part of the team.
|
| Matthew: | Thank you Danny.
|
| Danny: | You bet you. Thanks everybody for listening and have a wonderful day. Thank you. Bye bye.
|
1 Comment