Panel

Evan Light (twitter github blog)
Eric Davis (twitter github blog)
Jeff Schoolcraft (twitter github blog)
Jim Gay (twitter github blog)

Discussion
 01:30 - Dealing with unrealistic expectations

03:13 - “The Iron Triangle”

Cost

Performance

Schedule

04:02 - Bad management

05:07 - Establishing expectations

Prioritizing

Schedule & Budget

08:08 - Rescue Clients & Projects

11:34 - Developers are not interchangeable

12:03 - Approaching a project

13:55 - Business owner and end user communication

16:58 - Client Communication

Trade-offs
Hired guns

21:47 - Amateurs vs Professionals

24:04 - Managing communication expectations

28:57 - Engagement & Evaluation of process

34:24 - Wrapping up a project

38:36 - Types of projects

Clearly defined outcomes
Ongoing

42:23 - Client domains

47:33 - Influencing clients and teams towards better practices

50:30 - Clients that don’t want your input
 Picks

Kalzumeus Blog (Eric)
gfxCardStatus (Jim)
The New CTO: Uncle Bob (Jim)
Verizon LTE (Evan)
Kalzumeus Podcast 3: Growing Consulting Practices, with Brennan Dunn (Jeff)
IBM 168 | Earning Passive Income with Software, an Interview with Dane Maxwell (Jeff)
Anvil for Mac (Jeff)

 

Are we the optimal people to talk about this?

Oh, god. How are we going to start figuring this thing out?

Developer Edition” Practical Steps to Work Less, Travel and Make More Money. It includes interviews and case studies with successful freelancers, who have made it by expanding their consultancy, develop passive income through informational products, build successful SaaS products, and become rockstar consultants making a minimum of $200/hour. There are all kinds of practical steps on getting started and if you sign up now, you’ll get 50% off when it’s released. You can find it at nextlevelfreelancing.com]

Hi and welcome to the Ruby Freelancer podcast. I'm your temporary host in lieu of Chuck not being here. This is Evan light and today, I got here Eric Davis.

Hey!

Jeff Schoolcraft.

What's up.

Jim Gay.

Jim Gay?

Yeah, I'm here.

OK. Cool.

Thank you. That mute button is not working like I thought.

(laughs) Nice. And that is already in the recording. And today we are going to talk about Managing Client Expectations. So, who wants to get started?

the first thing that comes to me with managing client expectations is an experience I had on a project where, we were in crunch mode right in the start of the project. It was a rescue project and it was terrible code and the project manager was agreeing to his superiors that we would get x,y and z launched by a certain and who would come and tell us the date. And that's always a recipe for disaster. And we have a new developer come on to the project. He had been there like, I think he came on Friday and we had to do work for the weekend. So he, like his first start on the project was over the weekend, Monday morning.

We missed the deadline of course because things weren’t working right. And the project manager came in; we were doing our stand up meeting Monday morning and the first thing out of his mouth was, “You guys are killing me.” And it totally killed our morale. So right from the get go, we all have to put everything together and figure out, like, “Oh, how are we going to work on this person who clearly has a misunderstanding of what can be done on the project or with the development team.” So that was the challenge right from the get go for me.

In my experience, having worked in a lot of government contracts before with freelance, so many clients start with it every day. And then they give you the features, and then they give you the budget and then say, “Oh, by the way, none of it can change.” which doesn’t work. I'm sure that some or all of you guys have heard of that little pyramid where you got the cost, performance and schedule. And you can pick two, but you can pick the third. And clients and managers are always trying to pick all three.

“The Iron Triangle”

Yeah. I think the pyramid of Agile because they had quality in it or something like that.

OK.

It’s the idea that you can have something cheap really quickly and have all the features you want, but then its going to be really crappy code. I think its Agile is the first one that talked about like, that's a point on whatever the thing that you can’t be changing or you can’t change very much because it will affect everything later and they always change it.

Yeah. I was going to say, I was going to come with it but then I realized it’s not quite relevant to managing client expectations.

Well, my approach with the particular scenario that I was in; I was the lead on the team and (I went in a private conversation) went to the manager and said, “Look we are not going to have the ability to keep developers on this team if they are treated that way.” You know, “You got to recognize the effort that has been put in and all the good things that we did do.” And it’s when you find a bad manager like that, who is always looking at the next wrong thing; it’s really default to get them to change their perspective. It’s certainly worth the effort to try to do it, but once I pointed out that developers might leave, it sort of made him rethink. It didn't really change things except in the short term, (laughs) unfortunately, but that the threat of people deciding to leave the project was never-had never really crossed his mind. So, good management, I think I guess is where when I would like it to be.

So that's describing we are talking about a situation for a project that’s been around for a bit. What about for new projects? Whenever any of us get new client, we all-- well I assume we all spend some amount of time trying to establish expectations, right?

Yeah.

So, does everyone want to elaborate on that?

(laughs) Yes. [laughter]

Don’t ask a “yes or no” question. [laughter]

Oh! I fail as a moderator. I'm fired. [laughter]

I think sitting down and looking at what are all the things that we wanna get done and you know and getting someone to prioritize, is often a difficult task especially for those people who don’t want to prioritize. And you know, when they have everything is in the critical bucket, I'm curious about how others have explained to people, to their clients or to their potential clients that you cannot do everything and that you've got to relent on some features that you can ship some quality stuff.

When someone first contacts me, like the first thing I try to do is get their expectations of schedule and budget. I mean, most of the time those are fixed and schedules typically from an outside like, say there is a marketing launch they have to hit. And budget is, (depending on who you talk to) can be above the person you are talking of. So those are like usually the hard lines, like, these aren’t going to change. I try to get that upfront, so it’s like I know what I'm working with. And even just from me, I've had client saying, “Yeah. We need 40-80 hours of work done by next week.” And I'm like, “That won’t happen. I'm only one person. You are going to talk to someone else.” and I can just send that person or send that client away, right away.

Once I get that, that’s when I start digging in to like the features and like, you know kind of more like nitty-gritty. Almost like a top down type method for me. And you know, figuring out what bucket these features go and almost always, I try to refer back to their cost and say like, ”year, if you want all of these things in a critical bucket, that's fine, but we now have to pump up budget by two.” And I try to make clients commit to the bear minimalist that they can do, for like, a prototype. So like if a project is-- like their deadline is two months away, I try to do like a protype that is done in one month, using say half their budget.

And the point of that is because I know they are going to be filling stuff in and there are just going to be delays on from whatever. And trying to manage the expectation of like, “We are aiming for one month, that way you get your hard deadline.” That seems to work really good. And I try to address this in my proposal and give them other options that they want the whole thing planned out and every feature and all that. So, if they do have the ability to change some of these levers like budget, then they have those options.

So what I tend to do, because I end up working on a lot of rescue projects (although I'm oddly doing some greenfield now), I work with-- rescue clients tend to feel put upon used in the past and so they’re very sensitive to being let down by the contractor. So, what I usually tell them in terms of managing their expectation is, “I'm going to work with you to figure out what needs to be done.” Actually pretty much like how you described Eric. And you put it to something like pivotal tracker based on your priority. And just watch how much gets done and how quickly it gets done. If you are unhappy with the progress, fine. We’ll just part ways. All you’ve lost is the time it takes for iteration or two. And but on the other hand, if you are happy, (and I've never had a client throw me away after a week or two) On the other hand, if you are happy, then let’s just keep at it. And that’s worked very often.

Yeah and I haven’t done very mini rescue ones. Like, I've done some semi ones, like, where there's like previous code already there to do. And in that case, I typically, like I say, I still try and start for small project and I’ve done like week or a couple of hours by just to get an idea. I think in a lot of cases, it ends up like, “Oh look, there's so much stuff here that I have to work through.” I’m going to be starting off like 33% efficiency. And I try to set expectations like, “This is how I'm starting. I can go to 33% all the way up to 100%, but it’s not going to be a one day process. It’s going to be over the next few months as I start cleaning some stuff up or as I start gaining experience in this system or whatever. I'm going to get better and more efficient. But, we should plan for the worst case, that’s not going to happen. I’m not going to stay at 33%.” And it’s hard to tell that to the clients but that is kind of the reality and I think they have to know about it so it’s not a surprise.

So, you are always stacking up the task you’d expect to be least efficient on in the beginning or usual?

It depends. What I'm saying is, when you are dumping to a code base, it takes you a while to figure out things. Even if it’s like you need to build a basic scaffold model. Well, in a brand new Rails app, that's fast and easy because it’s simple. There is nothing there. But when it has a hundred models to hundred controllers, you are going to hit dependencies, you are going to hit other issues. And so do it in the same actual task in the different projects might take you some amount of time.

It’s not even dependencies, right? I mean I don’t know it’s probably a year and a half ago, I had something like. Customer come to me and said they need some help with his website. They were trying to do something with video. All I need to do is do this one little thing. And it’s not trivial like put it on modal over video, as soon as you click it, you got redirected to a purchase screen or something like that. So, I said, “Alright let me give it a shot. I’ll take a week or so and figure out how far I can get.” And then you dig in to it and it’s not just dependencies. I mean, third party, encoders and all those sort of stuff. I mean that’s on thing to deal with, but then if you get in to code that is written by somebody that doesn’t do things the way you expect them to then and you have to dig through all that to try and figure out what in the hell kind of crap this guy was on before you got the--

(laughs) sorry.

That's interesting too. So I mean, there are bunch of things that can work against you being able to jump right in. So it’s an expectation I think, (going back to the show topic) I think its expectation by clients and developers are interchangeable. And that they have team or some guy and did some work and for whatever reason, that guy didn't work but without any consideration for what that guy didn't work, the next guy should be able to pick up where the other guy left off and keep going just as fast or faster than the other guy.

So, in terms of setting-- I think it’s an interesting point, in terms of setting client expectations, you guys try to get a look at the code base first (I assume) before you do that, so that way you have—well, I'm asking I guess question again but I guess you are going with it?

I, to Eric’s point, if it’s a green fields project then you don’t have the code base to look at but, by the way I always try to approach is I always educate the client as much as possible about the problems that I'm solving. And I'm not solving the stereotypical programming problems of maths and algorithm and stuff like that, it’s just figuring out what is the business process? So you can sit with the client and say, “How does this work?” And kind of extract a model of what's going on in their minds and how the software either does work or will work or supposed to work. And if it’s a new code base, there’s tons of questions that you can ask. You can ask the same questions about an existing code base, but you can come back to it and say, “OK. Well, this is how you’ve explained it to me. I will now look through the code and here's what is happening. And this is how its different from what you say should happen.”

So it kind of gives a frame of reference to the client, so that they understand that you are actually working through a business process. You are not just pushing bits around. And they are left twiddling their thumbs and wondering, “Why is it taking so long to just stick some things on the database?” It shows them that you actually have to consider all of the different permutations of how their process works and then go and evaluate if it is existing code, what is it actually doing? Does is actually reflect what they say it’s supposed to do?

But likewise, you may have a conversation with the business owner, whose paying for the work and who you relate to on a regular basis. But then they talk to some other user and the user says, “Oh, no. We are not using it like that. We do it like this.” And so, sometimes, I find that my job is just getting those two parties to communicate. Where, you know, the manager who pulls the strings for budget and what not thinks it should happen a certain way, but the end-user says, “No we don’t do that at all. That is a completely useless feature to me.” And that's—sorry go ahead.

I was just going to say, what I'm noticing is up until now, we seem to be talking mostly about how we set expectations to beginning of the project. I'm curious how about (you started to talk about this a little bit Jim), how about on an on-going basis or an on-going project? You started to talk about it a little bit in the beginning Jim.

Let’s come back to that because I don’t think we've adequately covered this piece yet. I like what Jim was saying and I totally agree with it. I mean, if you have sort of best case client engagement from the beginning (and Jim, I like to hear how you map this out) but, so best case client engagement, you get some sort of some chunk of time with product owner or business owner that explains their domain and what problem you are trying to solve with the software. And then, another chunk of time to dig through the code and see if the code is doing what you heard the business owner is saying. And then have the quintessential come to this is what I found, this is what you said. How close do they match and then go forward. It sounds like the perfect customer engagement from an inherited project. And even though greenfield project, you are not looking at code but you have that other pieces to it.

Yeah. I think at least I always try and insert that process whether or not they are used to working that way, I try to have casual conversations about solving problems together. Because it forces them to ponder what are the requirements that you are giving me? Either you are changing the way something that currently works or you’re explaining the way something should work and it doesn’t. I try to have periodic updates. And it depends upon who you are on the team; if you are not a team lead and you are just sort of augmenting development, then you go to whoever your superior is on the project. So, you would go to the team leader, the tech lead and say, “Hey this is my understanding of what I'm supposed to implement, but this is how I found out that it works or maybe it does takes sense.”

I've been on projects where you can actually understand the problem well enough or you can go back and say, you know, “They want us to implement this feature but I see no real reason so do that because it just forces them to click this way and do that. Couldn’t we just short circuit it and do it on this screen?” or something like that. You know, even if the client isn’t used to that, I’d rather at least give them an update on it on a periodic basis. And sometimes I'm good about this, sometimes I'm not. Gather a bunch of things that have happened over the week. Maybe the development team trying to stay agile and the business people say, “We don’t wanna touch it.” But you can at least send them an email. Say, “Here’s what challenges we've come across. Here's what we have attempted to overcome them.” And at least keep your side of the communication up, so that you’re giving them all the information you can about solving problems. Not like technical details but--

One thing that I tend to do with my clients is that, they give me some idea, that are obviously in a form of requirements about what it is that they are trying to accomplish but inevitably, those requirements in one fashion or another, don’t meet up with reality; either the functionality existing app or there’s some technical hurdles to overcome. And so, what I tend to do, is frankly, I second guess my clients a lot. Not in a harsh way, but I go back and ask them, “Well, (you sort of talked about a little bit about this too Jim) that, you operate when it does this, you wanted to do that.” Or often, what I end up doing, it’s all going to be a technical problem too where, “You ask for his, but this might cost an awful lot or it might be terribly complex. Or actually no it might leave it complex. Here are some alternatives. Which one would you prefer?”

I think that is key too. I mean--

Yeah trade off. Is I think is essential.

Absolutely. And to second guess, you know, is really I think our job. Somebody hires you--

Well, it depends I think—I personally think it’s the difference between just being a “hired gun” and being a “consultant”.

I suppose, but I mean even if you are on a team and you are doing code reviews, to me anyway, doing a code review is someone else’s opportunity to second guess some aspect of what you have written or to help you rethink it. So, it doesn’t necessarily have to challenge everything, but you can play devil’s advocate and say, “What if you did it this way?” and just explore new ideas that you might not have considered?

--context of managing customer expectation.

Yeah but you know, if you are a hired gun, you are supposed to sit on development team, then evaluating the code is part of the--

Part of that. OK.

But I think, I would rather and I think sometimes I'm probably a bad hired gun because I'm often really-- I shy away from start-ups because I worry very much about their revenue model.

Guess what, I have the same problem but I work for them anyway. (laughs)

(laughs)

And I will often say-- I had one client and I said, “Well, you would really look an awful lot like Facebook. Are you really sure that you wanna do that? And they said, “But we want posts and we want comments and we want a feed.” And I said-- I asked them, “But do you think being derivative will make you successful? How many derivative successful start-ups do you know of?” Just giving a real world example that comes to mind, but yes I understand what you are saying there.

Yes. I mean there is certainly times when you know, second guessing that-- it could be valuable just for the business alone, but it might at least allow them to make decisions that adjust how they think about priorities, you know. They might have-- If a client has something that will make them money but they really are enamoured with some other idea, second guessing it, you can say, “Look if we look at the amount of time that the development team expects to be able to implement this or if it’s just me, or I expect to be able to implement this, we can spend three weeks on this feature which really matters or two weeks in this feature which doesn’t matter, just because it will take less time to do the other feature, you might actually get more for your bucket than if you just go a week longer and launch that than doing a thing that you think is awesome but will actually turn in to more revenue.”

I think that's part of being the technical expert on a team. And part of it is being professional to Evan says the difference between being something like a hired gun—

Consultant and a hired gun. Yeah.

Consultant and a hired gun, right. But I mean, it is being professional. It’s like everything else, right? I mean its updating your client on what you have been doing throughout the process. So that where has not-- they feel someone who would actually go away and they don’t hear from you until you ask for more money. I'm just saying it’s the difference between being an amateur and being a professional.

I mean, as a professional you wanna have your clients best interest in mind and even if you could ride some idea they had and milk them for whatever decent amount of money that they don’t even need to get solved. I mean, it’s the professional is going to say, “Do you really need this solve it or do you have to solve it this way? Or could we do something else?” This auction that you wanna do is insanely complex. We can do something else that is just almost as good as what you wanted but you get it done tomorrow or next week.

Fair enough. So I guess I've had several clients where they almost seem a little surprised that I have dialog with them about feature because I'm unsure that something that you finally do and that I accept that I might be wrong, but I don’t what them trying to provide what I think is constructive criticism but I really get complaints about that. It’s just that it seems that the expectation of clients, I found that in general, seems to be that they feel like they probably hiring just a code monkey; someone who will just churn out stuff. And they don’t know when they are getting someone or they are not necessarily even looking for someone who give them a value ad, if you will but, I agree that's one thing that separates professionals from not.

A lot that is the first impression you start with that client when you first engage them and price is part of that. And when I guess one of my picks will now be the latest Kalzumeus Podcast 3, something about freelancing rates. I’ll put up a link and that will be my pick. But the idea is, I mean the whole joke and I'm sure everybody is experienced it, that you have this idea that will make everything better and you’ve told whoever should be the person that signs off a hundred of times that this is the way you do it, they don’t do it. They go out and hire somebody for an exorbitant amount of money. They come in and do the exact same thing and it’s gospel because it came from somebody they put a lot of money to as opposed to someone they are not paying amount of money to and they think is just a code monkey.

The perception of value versus the actual value. Sure.

Exactly, yeah.

I remember listening to the episode on I think it was being agile or something like that and you know, Eric had some good insight there where he was saying, “Some of my clients wants to have the daily feedback” and other clients just say, “Here. We know exactly what we want. Take care of it.” And they don’t need the back and forth. And I think you know there are different clients now want things in a different way. And so I'm curious Eric about how you manage expectations with you know, with different clients. What do you do? How do you change your approach when you know some just want to leave you alone and have the work just done and others might actually want to have regular feedback?

Right. So I guess that's kind of like how do you manage like commination expectations. Typically, I’ll start of kind of like in the middle of the road. It depends on how fast the project it or it might be like you know, update a couple of times a week when I'm actively working on stuff. If I’m not actively working on stuff, less frequently. And typically using what the bug tracker is or just straight email. I've had some clients that are extremely responsive of that and are like asking for more things and more things and more things.

And so, in that case I've kind of in phase and like, “Okay, they want more communication and so I’ll do maybe a daily summary email or talk with them every week and have them a planning meeting or whatever”. But if they are now like not replying to email or taking a couple of weeks to get back to me and I mean you can kind of tell people like, “Oh yeah. Whatever you say. That sounds fine.” You know, that case I kind of back off and then you know maybe it’s a monthly summary or we meet every quarter or whatever. “Here’s the objectives we are going to try and do and here’s what it’s going to do to the business.” And I kind of give, “This is my professional opinion.” And then we hand it all then and then it’s after that it’s a very low key communication.

I mean, I just kind of get a feel for it and a lot of times, I just ask them like, “How busy are you? What do you expecting communication wise?” Because some people just they can’t get back to you. Like, they are so busy with other things, that or a project and so you know, you just kind of have to adapt.

Yeah. I always try to figure out what mode of communication does a client want as well, you know? Some people respond well with emails others just completely ignore emails and will phone calls are much better or in-person meetings. So, I always try to look for that too in that how can I actually best use whatever mode of communication I have their agreement on something and make sure they were both on the same page.

Yeah. I've been the same experience with clients where, you don’t necessarily know going in with their mode of communication is because it seems like everyone does have one or two that they are better at. The other part that I find challenging though, especially challenging is that, some clients communicate more frequently than others because they have very different priories. And I think it’s important for us to decide how much we are willing to compromise too.

For example, one of my first free-lance clients he delegated all the communication to a lieutenant essentially but a very junior one. Really didn’t have authority, really didn't have responsibility. But he didn't involve himself in the project. The project owner was not involved. And ultimately, that got to the point where we had some miscommunications because we are going through the lieutenant and I just decided that this communication problem wasn’t worth it and this it me was a anti pattern for projects.

Yeah. Like, one of my clients he's just busy like he runs a whole bunch of stuff

So I wanna scoop back to when Jim was talking about the initial part of the engagement and then answer to Evan’s question and felt like we’re in a presidential debate. We are talking about health care, “Yeah, I’ll tell you about tax increases.” or whatever we are going to do and so I answered that question I want and then the question you asked me.

But anyway, so I'm curious we are talking about this engagement and you try to answer that into a process Jim. I just want to make it clear with everyone listening and for me so, I can steal it next time I have to go talk to somebody. At what point have they signed a check and given you money to do something for them before—I mean, is there some sort of work product that comes out of the initial session of client to talk about what the business goals are or what the problems is they are trying to solve? Or is it just some cost of doing business you accept upfront and you try to limit it to some period of hours and the you go on after that to look at the code or what?

I’ll give you an example just a couple of days ago. Somebody had a project and they were unsure that their development team was doing things properly. They were unhappy with results or seem to take longer than they expected. So, I was contacted and they said, “We would come and review what we’ve got. These are the problems that we’ve been having.” So I took a couple of hours, had a phone call with them for maybe an hour and asked them to send me some details about what problems they were having. I reviewed their code in their site and I took a look around and I gave them a report. And I said, “Well, the first thing I found was first of all, you don’t have a backup strategy. So turn that on right away. Second of all, you know this--” and I would give them a level of like, is this significant or insignificant level of effort to adjust it. And that you know made it by like that so it is easier to decide on what to address. And discussed how these things affected what they wanted to do.

So, they may have problems where for example, if it’s like CMS. They just wanna edit their site and things aren’t working properly, what level of effort does it require them to do manually versus the amount of money they need to spend to fix something to move that level of effort. So we would have a discussion. So I would review their code, review what they are doing and then go back to them and discuss the findings. They’d have a chance to look at them, but they won’t have another conversation and usually, it move forward after that.

But even so, on projects where I haven’t done that, I've been hired to come in and help kind of do the same thing like on a rescue project. And they explained to me, “Here’s how it works.” I'm already on board and I still have to do evaluation of their process. And you know, I haven’t done the last greenfield project I did was probably two year ago at this point as yeah, or maybe I finished that a year ago. But my brownfield stuff is usually where they explain, “This is how its working and these things aren’t working quite right.” And I just try to get as much plain English conversation done about what's supposed to be happening. Because the client always has this understanding of how things should work that is slightly different than how it actually works or how it even can be done. And I just try to keep that kind of conversation going.

So you know, over a week or two weeks or something, depending on their level of involvement, if we are doing a Scrum type of process. I try to do the best I can to at least inform them, “Well, here's the challenges that we came in to. This is how you described it working. This is how we found it actually works or this we think might work better if you do this.” So, for me it’s an on-going process and sometimes, I have to have that conversation, other times I don’t; everything works as expected or along as planned and the updates are reasonably small. But I try to make sure that we address the issues before we actually starting having any code for it or if we are in the middle of putting code.

You know like, if we are doing a daily meeting with the team, I found success in just killing off the “What I did yesterday” part of it. Just say, “What do I have to face today and what's blocking me, because what I did yesterday doesn’t really matter unless I'm actually doing something today and related to it.” It shortens things up. And it’s nice to be able to get the client to focus on what needs to be done. So, if there are blockers, I could say, “Hey, we found that this doesn’t quite work, right? We need to have a conversation after this meeting.” That's generally what I've done but I try to keep it formal.

Yeah, it sounds kind of like what I think Eric were describing earlier. Just giving the clients regular updates and telling them about the trials and tribulations that come along. And keeping them informed, giving them options at least that's what I heard.

Yeah, absolutely. For sure. Because it’s always balancing things; “We could do it this way. It could take longer but, how bad would it be if we just have the users do all these stuff manually until we have more time? We have bigger problems, so let’s solve those problems instead of fixing this minor bug to save people five minutes of work.”

Okay. So, let’s take a different tactic this time.

No, no.

What? (laughs) you got five minutes left though.

Five more minutes. You can do it when I'm gone.

All right, fine.

Just the last thing and yeah okay. This is the last thing, I mean definitely relates to setting expectations, I got to lead--

I wanna hear the answers to my questions from you but anyway, go on.

All right. Then you can answer mine quickly and I’ll try to answer yours quickly. So, it’s the typical “I've been working on project, I need to transition to a new developer. 70% done, 80% done some percent done, you need to learn it by November.”

That's awesome. That’s actually very much what I want to talk about. (laughs)

All right. At least it’s the same thing because I mean and this goes back I think to the machine that you are just replacing. I think its 70% done. It’s taken X long to get to 70%, again extrapolate the next 30%. I'm saying, client thinking here.

Yeah.

It took two months to get 70%. You can do that 30% in a month. I mean software is linear, right?

(laughs)

No. I mean it’s just interesting that lead came up and this topic came up very appropoing.

I guess I'm not sure that you are asking exactly--

I was just--

You don’t know exactly what I'm going to ask but, what I was burn.. no I'm kidding what I was thinking was, how we talk about the beginning in the contract, what about setting expectations about the ending of the contract, which sounded kind of like where you were going. Transitioning off.

No. I was answering that. I really didn't ask a question, I just made a statement.

Fine. Good statement.

(laughs) Thank you. I appreciate your appreciation of my statement.

So, what do you guys do when you’re trying to wrap up a project in terms of setting a client’s expectations and I guess there are different ways to wrap up a project its either you are leaving before it’s done, for whatever reason or you are finishing it and delivering it?

The second one is easier, right?

Yes it is.

It seems to be easier because there is a clear path. I mean, you have met whatever the business goals were at the bringing. And you got a product maybe there is ideas for future improvements, maybe there is some sort of follow-on work that you need to do, (not follow-on work) but there some maintenance you wanna provide them, how are you going to support issues that come up in production and for the next month or two months or whatever it is because you guarantee your work or whatever the scenario.

I think that that's—it’s a nice scenario to be in, but I've only had one project in recent memory, that has ever did so cleanly and so nicely. They’ve all just continued on or continued the frequency of which I interact with the project had just dropped dramatically. I had one client that we do exactly what they wanted, it was some customization to RedMine to give them a dashboard for a big screen to do their big visual stuff and it works, they got their 1.0. We said, “We’ll contact you We’ll follow up on a couple of weeks, make sure everyone is going good. So if you have any improvements for version next or whatever.” And it sort of stopped. I don’t know if they--

That makes sense. I mean it’s easier to if the scope is narrow, right?

Yeah.

Because I had a project of kind of medium size, go write a recommendation engine. But the goal was kind of obvious, its write a recommendation engine. When I was done with that, they had me some other work and I was fine with that but, the goal was obvious, once I had that done then everything else was just on both sides.

You'd be talking about that on Ruby Conf right?

Yeah and sensibly I'm going to try and open source it. The clients are willing to work with me on that I just have to do it. But thanks for that JIM.

Looking forward to seeing it.

Oh boy! (laughs)

(laughs)

I definitely agree. Narrow scope definitely helps. I mean when you’ve got a big project or some ongoing project, it sort of seems to never end. And that beeping, if you can’t hear it, is my next call.

So I'm going to drop off guys.

Thanks Jeff.

Thanks for the show. Talk to you later.

Yeah. Well, I hate to put you on the spot, but Eric I haven’t anything from you in a bit, do you have anything to add?

Oh, I got lost at that.

We are just waiting.

So I was trying to think what Jeff was talking. Like, the vast majority of my projects fall in to two groups; it’s either one we need either this feature, this set of features or this outcome. And its very-- well, it might not start that way but it ends up its very clearly defined. And once the work is done, the project is done, it’s shipped. You know, whatever they do, they QA and test and it’s done. It’s a very like this project started and this project ended. The other kind of camp a lot of my stuff run into is the-- I wanna say maintenance, but “maintenance” isn’t the right word; it’s more like I have an on-going contract with a client for a year or two years or three years and that contract says, “I'm going to be giving them x amount of my time.” And they can use that on whatever.

Very clear constraints?

Yeah. And so, like, for instance one of them was like, “20 hours a month for X amount of dollars per hour.” It’s almost fixed bid. If stuff doesn’t get done in a month, it gets pushed off in to the next month. And so, it’s very, very lightweight Agile. Like, okay its October, what's the most important thing we can work on right now, that's what we are working on. November we will review that and see what's the most important thing then and it could change. But, there is no clear done as far as like, software wise but there is like okay, the contract is over and its either, “Are you going to renew or not?” And so there is still the clear calendar like this is once it gets done, and going to if that is the expectation. And it seems to work really good I mean I had a couple of them that where going for, I think like 3 or 4 years straight and some of them were like we want as much time as you can give us type thing. So that is kind of how I set expectations at the end of the contract its actually, I set it at the beginning and so, the ending is actually relatively clean.

Well that makes sense. Interesting. So the on-going contracts, these are I assume production systems or actually, no, right you said you are just working for the client. I think it can mean on varying capacities not on necessarily any one app then, right?

For the most part, it’s for one app. I mean, most of it is either RedMine or Chili Project. And so it’s one app. It’s always production I mean I might do some prototypes, but the goal of the prototype is to prototype something that we are going to put in to production later. Like, how we are going to technically accomplish something. But yeah, it’s all production.

I guess one client is started at with working on App A and we kind of added in like an App B or an App C later. Like, there is no real—You know, they weren’t service apps or anything. That is a completely separate scope, separate project. But that's still kind of fell under like, “Eric you have like this bucket of hours for us. We are going to pull a couple of hours for App B and App C.”

OK. I guess I've had a bunch of different ones then you described the way that you have been working in your second type of contract. I suppose one of my clients, I started out that way that we could use you on-- we have production assistant and we could use you to up to x many hours adding features and handling and fixing bugs. So to that extent, I would sort of staff augmentation, but I was also mentoring their team too. But then, I tend to get, I’ve gotten a few of the “Just go build a greenfield go build this for me app” and rescues are maybe a whole different special ball of wax.

Yeah. Like, we said like many times, I tend to work on different projects than everyone else here. Most of my stuff, like science and news stuff that is actually different but most of my stuff has been internal business apps. They are all in production but they are not like mission critical.

They are not customer ***?

Yeah. Exactly and so it’s almost all of my apps are very much driven by the business goals. And so my they are very like, “We are spending too much time this area. We need to automate stuff. Or we need to get clear visibility in to this process.” And so, having that kind of business objective means I can really clear up the requirements versus, “We wanna build a start-up and lunch this public site and make millions of dollars.”

Right. I think it might be relevant because I don’t know if we mentioned it too often in the podcast, I

tend to do mostly start up clients. I guess it’s because I get my clients mostly through spoken at some Ruby Conferences. And Jim, what kind of domain would you say yours are typically in?

Well, I don’t know. I’ve had--

(laughs) ok.

(laughs) I've had that small--

Ruby?

(laughs)

Does that answer it? I've had small projects. But mine has always been either plain design or front end development and backend development. But--

*** though?

Well, I’ve been pulled in to government contracts. Like, I did a DC public schools contracts that was a long running contract, I did association work in like a large non-profit organization, done start up projects. So, I haven’t really found like “niche” clientele, but I do often help augment teams. So like a consulting company might come to me and have me be a part of their team rather than a--

Rather than working directly for a client?

Exactly. Because right now, I'm just one person. I used to have a partner and employee and so we would kind of be partners on things. But now, doing it alone, it’s much easier to just go in and help a team address something and they already got their project managers in place and sort of they take care of some of the details.

The reason I asked this question is I just thought it will be useful to get to the audience to get a sense of where our perspectives are coming from in terms of describing customer expectations.

Because I wonder how much difference it might be across domains, perhaps.

oh, I think there is a huge difference. I mean, I've done some work start up stuff and I've done some like, what did you call it.. Team Augmentation or whatever. I don’t do that that often. I don’t enjoy it you know, its whatever. So I've seen like the whole project is different. Not just like using different code, but like the feel of it, the way stuff happens. I mean, I think they are a completely different piece. That's why like I bring up a lot because whoever is listening, like depending on what they do, most like they do that start-up stuff, some of the advice I have might not work for them at all. I mean, I worked at established businesses, people who doing internal stuff, versus Evan, you do a lot of start-up stuff, your advice might be better for them. And it’s hard and that's why I kind of like the different perspectives we can bring because it’s--

They are good for all of us to get a bigger perspective.

Yeah and you can always cherry pick stuff too.

Yeah, absolutely. And I think Jeff’s, he’s had a lot of government contracts, right?

Yeah, I wish he was here. I didn't know that.

Because me and Jeff talk a lot outside of this, but he does a lot of start-up stuff. He does some… I think he’s done considerable amounts of team augmentation stuff and a touch of government. I haven’t heard much. I mean, we don’t know exactly who we work for, it’s just kind of like the size of project or that source of idea we get.

I mean, in my case, I’ve done staff augmentation for start-ups because usually, really the staff augmentation for start-ups often is a rescue, often is a mentoring effort. And that's partly because I

guess, not necessarily how many hire me, but some people do hire me specifically being a mentor but it’s also how I tend to approach it. And this is also very much a matter of setting customer expectations, that a lot of the time, they will bring me maybe just to add more code, but I want to make them better because I don’t want to be cleaning a bad code all the time. I would like to help make them more productive. So, I’d like to add value in a bigger level. So, there's I guess you can say there's a little bit of a “dance” that I’ve been learning. No, not exactly a dance, if you will but, there's people skills that I have, there are definitely people skills that are involved in trying to walk that fuzzy line to influence clients or their teams toward better practices. And managing expectations that way.

What is it like not politics as in like democracy but politics as in like the organisation as in how communication flows and all that, those kind of skills. That's why I don’t do a lot of team augmentation. I’d say 90% of my projects, I'm solo with the client working at the pm or me being the pm. And that’s where I have done a lot of my work. And a lot that is because I work closely with them and like, “Okay, this feature is not going to be good for your business.” Like not that the feature or technical problems, it’s all like helping their business. And I felt a lot of the stuff augmentation, you kind of get-- you leave a lot of consultant role and get more code monkey on the keyboard rolling. And so, business is my passion, so not being able to tell client like, “You are making a business mistake here.” is really hard.

I still do that even when I do staff augmentation. I guess it’s to say that I try to change the rules when I'm brought in for stuff augmentation. But I guess it’s also because I’ve never been brought in really just for staff augmentation.

Yeah at least like the level of it. Some of my projects, from day one once you get all that stuff, I will tell them like, “You are making this mistake.” to like, “You are doing something wrong.” With staff augmentation, you kind of build up some political--

Yeah build up credibility. Yeah. You are exactly right.

Of course I am. (laughs)

Oh, god Eric. You can’t go in to an existing team and just say, “Yes. You are wrong.” You can, it’s foolish because then no one will listen to you. And that is a matter or building up credibility which take some time. Although-- and it’s worth adding, or even especially when your brought in as a consultant, they want you there to mentor, even though that's how they brought you in, it’s rare that everyone buys into that. And so you would have to-- you are given authority, but it’s not earned authority. And so, it can be difficult to live up to that expectation as well.

Well, I mean, it’s also when you are kind of a consultant, you’re giving them advice. They don’t have to take that advice, I mean it’s probably in their best interest too because your consulting on something you are an expert on. And sometimes that might lead over into like you are giving advice on their development stuff. They wanna take that advice but they don’t have the experience to do it. And then that's where you kind of help, like do mentoring or by do help with the implementation. Like, maybe you will pair with some of them and show, this is how you do some of the stuff, like actually code wise. And that's where its— I wanna say at that point, you are not actually acting as a consultant, you’re acting more like trainer. You are training a team now.

Yeah, right. Yeah it’s probably way late in the podcast to be raising this issue, but there is also the client who won’t take your advice, who wants you to just be a code monkey. And it’s that difficult client who maybe you care what the project, but you don’t care about the people or maybe don’t care for the people you are working with or their behaviour. But I, at least whenever I run into that, I always go back to my initial approach. I just have to start asking questions and so, you can kind of use the *** method to help them along in figuring out where the problem are if they won’t listen to you, explain what you found. You can at least ask them questions that will help get them down the right path of figuring out whether or not they can ship something on a certain date or within the budget or whatever it may be.

You know to be honest, and this is because I try to come in more as a consultant more than the person type in if they don’t take my advice especially if they hired me for that, I get rid of them. I

mean I’ve left clients-- not that they refuse to take my advice, but they refuse to believe I'm giving them advice and that I was helping them. And I told them like, “Look if you are going to pay me to do stuff for you and I'm not helping you, there's no sense of having this. This relationship is not going to work.” And I say, “We are going to cancel our contract. We’ll go our separate ways. Best of luck on what you would like to do, but I can’t be a part of it.” I mean my opinion, there's too many projects, there's too many clients, there's too much code out there that I can actually help. I don’t wanna help people that don’t wanna be helped.

Well, and that's-- I wonder if we can get a whole different topic of discussion on this one, but that is one of the tricky things about consulting. If you go look at Gerald Landsberg’s book, we are hired because there is a problem. And the problem is usually a people problem. One of the interesting situations I've encountered is when you are hired to solve a people problem but the truth of it is when you work towards solving it, they don’t actually want it solved in the first place.

Yeah, well to be honest, a lot of, not a lot. Sometimes consultants aren’t hired to solve a problem. That's what they said. They might be hired to be the fall guy. They might be hired to, “Oh, look. We tried everything.” But you have to also admit; sometimes it’s a consultant at face value. You are not hired to actually solve anything.

Well, I tend to take people what their face value for better or worse. When they bring me in to provide advice or insight, they don’t have to take it well, but if they are not taking any of it, then I agree with you. I've had this on projects where, I don’t think I'm being useful anymore so I'm going to leave now. It doesn’t necessarily go as well as that, but I've had that once or twice. And I’m not sure where we are going with this beyond that. So, speaking of which—

***

Yeah, (laughs) thanks Jim. Do you got anything else, Eric?

No.

OK. So, having said that, why don’t we get on to the picks. Let’s start with Eric.

So, Jeff picked it too, but I would actually go in more meta. But Patrick McKenzie, his company name I guess is Kalzumeus. I'm probably not even pronouncing it right, but he’s been writing a podcast for a while, like a couple of episodes. He's been doing couple, I guess three or four recent ones on more freelancing consultant stuff and pricing and marketing. Really good, really long but it’s worth it. I listened to his latest one last night and I think I sent myself like 6 emails of things I need to do. So, if you haven’t subscribed to that podcast, subscribe to it and also subscribed to his blog. He also has a lot of great advice on marketing and like business stuff, but it’s around software. I mean, he’s approaching up from a programmer perspective, so it’s very easy to take and put in to a freelance business if you are a developer.

Okay. Jim?

The first one I found out about actually previous Ruby DCamp, graphics cards styles gfx.io and this is little tool that you can load on to your Mac for a laptop, that will switch between using different graphics driver. So, if you are unplugged and using battery, it will use the lower power usage option or if you’re plugged in to switch to the higher one. It does things automatically depending upon what application. Chrome for example, will always for some reason use the higher powered one and there's even a recommendation that you use Safari when you are going on battery because it uses the less power graphics. Anyway. This thing allows you to switch back and forth the one thing that I did find with it when I had first installed it, I thought “Oh, I just try this out.” And I thought to give a presentation at DC RUG and I couldn’t-- like the projector wasn’t working. I don’t know why. And it took me-- like someone had to restart and someone had to do their presentation before me, because I had to what the heck is going on. And anyway I just had to switch the driver and that it works fine.

So there's that and then I don’t know anybody has seen Uncle Bob had written a blog post back in September called “The New CTO” and it’s a great conversation starter. Just about how projects are managed and how the development team—I t’s basically like a short story of how development team is responding to things that was said and how they are going to get through writing tests for all the their code, how is that even possible and how are we going to deliver on time. So those are my picks.

Okay. I just have one pick and that is not my iPhone 5, but Verizon LTE let has made my life so much better. I tend to work outside the house, maybe a third of the time just for variety, and sometimes I travel. And 3g just does not cut it a lot of the time, especially for trying to go look up docs in the internet. I'm always surfing API docs all the time. And the 4g is breath taking. It’s about as good at being at home pretty much wherever I am as long as I have access to LTE network. I'm not advertising for Verizon, but their LTE network out here in the eastern shore, considering I'm kind of in the middle of nowhere, its shockingly good. So, I've been very happy with that plus it makes a lovely backup for when my cable company fails miserably in my internet connection goes out. I guess that makes a wrap for this show. And next week--

I don’t think— did we go through Jeff’s picks?

Oh, right. Sorry. Ok, Jeff alluded to them very briefly early in the podcast, but Jeff had a particular podcast, the Kalzumeus Podcast Number 3: Growing Consulting Practices. And then, a link to-- I haven’t looked at this one yet, Internet Business Passive Income with Software. A mouthful of a title. Sounds like passive income from writing internet business, I guess. Give those a listen too.

And then he just threw in to our chartroom “anvilformac.com”

ERIC: and what is that? Like a Mac app of some kind?

It’s a beautiful menu bad app for Mac.

Oh right. I saw this. This is for using PowerDocs, which is I use that sometimes at home too. It’s powered by Pow. So, it’s not a front end for Pow, I think it actually wraps Pow. I haven’t started using it yet because I haven’t been using Pow a ton lately, but the UI looks pretty nice. And if you haven’t tried Pow, (its maybe I should have given this a pick before) it’s awfully handy for writing an awful lot of web apps locally on your machine just for developing purposes or testing purposes.

OK. So, unless there is anything else, I guess we’ll make this podca-- podcast (I can say that.) a wrap and next time I hope we’ll have Chuck move back, so that way I'm not moderating (laughs). Alright thanks a lot.