We all know the story. A client comes to you and poses their problem. You assess it and reply with a proposal. The client accepts and the project begins. Work. Work. Work. Finally, the project is completed and everyone is happy, right?
It’s almost never that smooth. At Four Kitchens, we’ve been there, we’ve learned a lot, and we’d like to share that with you. Watch the November 2016 video from our webinar series “Four Kitchens Presents: Getting What You Need” to learn all about:
- What to expect during each phase of the project.
- How to understand and articulate your needs.
- What causes overages in scope and budget.
- How to clearly communicate when you see problems.
- Why is it taking so long?
|S1 00:05||Hi everyone, welcome to our webinar. Today, we’re presenting Four Kitchens getting what you need. Mike Minecki and Jon Peck will be guiding us through the complex process of ensuring that your client project is successful and on budget through accurate information gathering. We all know that what we say isn’t always what we mean, and sometimes a client will want something, but they don’t really know that they need. Both Mike and Jon have been there so will be teaching you how to make the most of your time and ensure your success. We’re going to field questions at the end of the presentation. You can use Zoom’s question feature, or you can tweet us using the hashtag, hashtag needsbswants. All right, let’s do this.|
|S2 00:53||All right, well thank you very much for coming. My name is Jon Peck. I am a senior– I’m an architect at Four Kitchens. I’ve been here for about two and a half years. I’ve worked on a variety of large media projects. And I’m joined by…|
|S3 01:09||Mike Minecki. I’m the director of technology here at Four Kitchens, been here for about five years. Worked on a variety of large projects and now oversee multiple teams that do that across our company.|
|S2 01:27||So today we are going to be talking about getting clients what they need. So it’s easier to articulate a want versus a need. So let me define exactly what that is. Needs are the goods and services that are required in order to be able to get something. And wants are goods and services that aren’t actually necessary, but are desired or wished for. So that line is often blurry and one influences the other. The goal is to translate what’s being requested and it’s something that the audience needs.|
|S2 01:58||So, to illustrate this, there’s this website called projectcartoon.com, and it provides a builder for this particular cartoon. It’s a fantastic illustration of the problems that can occur with communication. A customer explains this swing off a tree that has three tiers. The project leader said, “Okay. Oh, you want a swing? Fantastic. But it can’t actually swing back and forth.” A programmer took a very literal interpretation and said, “Okay, you want a swing? You’ve got a swing. It’s off the tree. No problem.” He didn’t specify what part of the tree, so I did it and my work here is done. At the end of the day, the customer needed a swing, but they actually wanted a tire swing.|
|S2 02:43||And there’s a very real world application for this, and I’ll tell it as quickly as possible. A large media company had a system for classifying content for– they had movies and music and actors and so forth. The editors wanted to be able to classify content as such. Readers just wanted to be able to access content. There was a very complicated system in place, and as part of our migration we were going to try to build that exact system and unify all the data into a brand new managed taxonomy. Spent months and months putting it together doing hand reviews of content and all sorts of different things, and at the end of the day, all the editors wanted to use was WordPress style free tagging. We put massive amounts of work into something instead of actually asking the editors directly, “What is it that you really need and want to use?” So learn from our mistakes and we’re going to discuss how that’s going to happen. So getting what you want doesn’t always get you what you need, and that was a perfect example of that because the client got exactly what they asked for. We built exactly what they asked for, but it wasn’t what they needed.|
|S3 04:08||So a quick overview of our agenda today. We’re going to quickly go over what it takes to make a big project successful. Sort of the outlining the different steps in our process, as an example. But really, this is a modern software development process and is applicable in a lot of other situations. What you should expect in each phase of the project process, and what you can do in each of those phases to make the process more successful. We’re going to dive a little bit into how to solve project problems, and what to do once things have taken a turn for the worst, and answer the question that always seems to be on people’s minds. Is it me, or is it my vendor? We’re going to talk about the top things you can do to make your project successful. Before we dive into the [inaudible] of this, I just wanted to take a moment to answer the question, “Why are there two engineers talking about a project management process?” This presentation came out of a conversation between Jon and I, about a presentation that he put together outlining what it takes to be a good saw for architect, and how to avoid over engineering. In the conversations that that presentation spawned, we really dove into all kinds of things that Singer engineers and architects need to learn about communication, about what their role is in the process. And it really came to light that a lot of those same things apply to the clients that we’re working with. So we wanted to kind of walk through what you can do as a client to make the project that you’re working together with somebody on successful. A final note, the software development process and kind of understanding where things are at; it’s not a project manager’s problem. It’s really something that everybody who’s involved should be engaged with.|
|S3 06:23||So, a quick intro to our process. Before we talk about how things are going, we talk about how things are and outline pretty quickly about where the different stages are. And in the next slide– so here is just our general process. And this really applies to just about any shop out there. Some of the words might be a little bit different, but really all software projects go through the same stages. In discovery, you have an in-person workshop usually followed by some research, and at the end we deliver a needs assessment. Many times this is happening without a vendor internally and is kind of before an RFD process, but it can be very useful to have a vendor there and engaged in the process. The next phase, and this is usually bundled together with a discovery, and most organizations don’t make a distinction. This is where we kind of take the big dreams that we have during the workshop, and turn them into specific requirements, and start the process of prioritizing what is going to be in this particular project, and what is going to be held on for later. Really defining the what, the why, and in a broad sense, the how. These two things pulled together equal the scope of a project. And many times, as I mentioned, this actually happens before organizations engage a vendor, and I’ll touch on a little bit later why that can sometimes lead to problems. So once you have the scope, then next is something that everybody’s familiar with, it’s the design and architecture phase, usually involving user experience in the vein of wire frames and familiar things like that, like site maps. Visual design, so getting down into the visual makeup of the site, the visual language, and doing things like style guides, style tiles, and maybe even fully fleshed out comps.|
|S3 08:55||On the technical side, there’s the technical architecture, so making the plan for how the system is going to be built, taking into consideration, the requirements that define the scope, and making sure that the systems involved are accounted for so that the build phase can go smoothly. This is also an ongoing period of prioritization. All organizations– this is going to happen regardless of whether you’re doing it consciously or not, and now you’re going to be making decisions as to what design first, what parts of the architecture to define, and making those decisions really is what defines what gets built, and really should be a conscious effort rather than something that is just sort of backed into by selecting the flashiest features or the most fancy things.|
|S2 10:08||So when you enter into the build phase, we use the agile project management, which– it’s a pretty typical implementation the way that we do it. It’s two week sprints with thin vertical slices, having a daily stand up, having an open Slack channel to facilitate communication between the client and the engineers who are working on it and ensuring that there’s a biweekly budget and scope check to make sure that everything is in alignment. Part of what we strive for is a minimal viable product, or an MVP. And this is building something that is functional enough that you can actually use it and provide feedback. It doesn’t necessarily mean that it’s going to be complete; it just needs to be something that is tangible that you can actually provide feedback. And we’re going to get into that in a little bit more detail later on. Our development methodology therefore, is going to be prototype, creating that kind of minimal product. Implementing it, testing it, making sure that it’s meeting the expectations. It’s like, if you expect that it’s going to be blue and you look at it and it’s orange, it’s not meeting those expectations. So making sure that it’s doing what it’s supposed to. And then iterating, “Okay, now it’s blue. Well it’s supposed to be square. Let’s make it square. Okay,” and so forth, building up from there. And finally, migrations. This is optional, it depends on the project. Some projects have it, some don’t. Migrations are when you have existing content from another site or structure, or even that isn’t involved in the project, but you need to bring it in in some way or another. It’s the process of transforming the content into the new unified structure that will be the results of all the work that’s happening.|
|S2 11:59||So once the site has been built and thoroughly tested, it’s ready to go live. We’ll work with you to coordinate the launch to [ensure?] a smooth and well-publicized introduction to the new site. And that when the site launches, it is feature complete. It has all of the major components that are necessary. Often, sites will launch with a subset of features and continue to build and iterate. Other times, they’ll wait until every single piece is complete, and then start polishing after that. And at launch, all the content entry, either migration or manual is complete. We’ve gone through performance testing and tuning, making sure that the front end and the back end are– performance are caching properly or hosted properly. There’s production environments that are stable. Everybody who’s involved knows what that process looks like and so forth. And then the actual active go-live, which in the goal, is to make that as boring as possible. Often, it’s the actual act of going live is just making a small change to the DNS record and you refresh the page after a couple of minutes, and it just loads new and everything’s fine. That’s what we strive for. Sometimes we have incredibly boring launches, and it’s fantastic. Sometimes we have exciting launches that– this is real life, sometimes things go wrong and we’re there every step of the way to ensure that everything is taken care of.|
|S2 13:31||And then I enter into kind of post-launch adjustments. Once you getting real users into your system and you start exercising it fully, sometimes you will discover user cases that you hadn’t considered throughout the development process, or you might find a bug or what-have-you; just unforeseen circumstances, and you just need to do a cleanup. That’s a natural part of launches, and it goes right into support and continuous development. So after your site goes live, we transition your project to our expert support team, making sure that you get the attention that you need for as long as you want. We also help transition either internally to us, or if you have an in-house team that may have been working with us throughout development, ensuring that they have the documentation and institutional knowledge necessary in order to make the site successful as possible. Our dedicated support team is available, and you have full-time engineers whose job it is to make sure that the site is up-to-date; that incremental changes or bug-fixes are taking place, not only that the lights are being kept on, but there’s no dust anywhere, there’s no bugs and so forth. And we look to establish a long-term partnership, and be able to make that differentiation between when there is a problem with the system, that there’s a bug– there’s an expectation that it works in a particular way, or it’s like, “Hey, is this an opportunity for a new development?” Once the bugs are fixed, are there some extra hours available to do this within the scope of support, or is this going to be an actual new project? And then we can have the conversation at that time.|
|S3 15:29||So that’s the quick overview of our process, but really, any software development process. You start with discovery, uncovering and detailing the needs, definition, planning the road map, and understanding the scope. Design and architecture, developing the patterns and models that are going to guide the rest of the build. Building, cycles of prototyping, implementing, testing, and then repeating. Launching, hooray if it’s easy; sometimes it’s hard. And then moving on to an incremental support phase.|
|S3 16:06||So next we want to dive into a little bit about how do you measure success in each of these project phases? The first part to understanding that is understanding how to properly proportion the different phases of a project. No project looks like this, where the discovery and the build take the same amount of time or the same amount of budget. Most of the time, and a really common mistake, is that you end up with a project that looks like this. A very long and drawn out design phase, followed by a really truncated build phase that doesn’t– that’s really rushed, and doesn’t have the right level of resources to make the project successful. Also completely missing here, and many times, are considerations for long time support for a project, or a dedicated launch phase where the project is feature complete, but isn’t out in the wild yet. So a more balanced approach is something that looks like this. Discovery and definition– discovery, definition and design, taking about a third of the project timeline, but usually a smaller portion of the project cost. Followed by a robust build phase where there’s lots of opportunity to continue to design and iterate on features. And that there is time to actually get hands-on, either internally, or user testing the features that are being built to reduce the dependence on assumptions.|
|S3 18:15||Finally, a dedicated launch phase that allows our project to be feature complete before being pushed out the door, and a support plan that is established at the beginning of a project and is understood. And that can be something like a transition to an internal team or support from a vendor. But in either case, understanding how that’s going to play out at the end of a project can define some of the decisions as we’re really strapped for time, for example. Building features that require a great deal of support may not be the right way to go. So this is a great way to make a project successful, and if the project is proportioned like this and can stick to these guidelines, it’s going to guarantee to be better than just spending a year in design. Kind of taking it to the next level is a more iterative approach where the project or website is launched incrementally and the features and a portion of the project budget is dedicated after the build. And that’s different than support. Support is keeping the wheels on, making sure that the oil is changed, but it’s not adding a new trailer or something like that, if we’re going to use the car analogy. But dedicating a full team on a build after a site is launched allows you to get the feedback from user testing, see what features are actually providing value, and which ones are not, and really reduce your dependence on assumptions made internally or early on in the project. So that’s one of the most important things that you can do to make a project successful, is make sure that the right amount of time is allocated to things like design, discovery, build and launch in proportion to each other and really changes based on the scope of the project, the size of the project. But the rule of thumb for these can– it can really translate across project sizes.|
|S3 21:05||So how do you know if it’s going well in each one of these phases? Kind of after working in this industry for as long as Jon and I have, you kind of just have a feel for it. But hopefully we can give you a little bit of better ideas what that feels like. So in the discovery, is the vendor asking a lot of questions and learning a lot about you? Are you learning something new about your organization? The discovery should really– is an opportunity for an outsider to see in the inside of your organization, and many times give you insight on things that you’ve just taken for granted. What can you do to make a discovery phase really successful? The first is to learn. A lot of it is going to be a vendor asking questions or internally, teams asking questions, and it’s very important to sort of stay open to understanding and changing assumptions. And finally, getting to know what is motivating your vendor in this project? Nobody gets into a relationship for a large web project just because they need to pay their own bills. There’s motivations for getting into your industry or working with your giant enterprise company. Understanding what is driving the vendor’s needs can help you understand what it’s going to take to make that successful. So during the– oh, sorry Jon [laughter].|
|S2 23:03||Oh, no worries. Yeah. So in the definition phase, the ways to check to see if things are going well is, do you actually understand the scope? And both you and your vendor can actually clearly point to what’s important. The big warning sign is if you’re getting everything that you ever dreamed of. This is usually disingenuous or inexperienced. There should be clear documentation between what the business [goals?] and features are, there should be a clear understanding of what is possible within the budget, which can be either monetary or time, and usually time is money, so it’s the same thing. There should be a priority of the features and you should have a way of sharing that within the organization and just being able to see what’s coming up or what’s going to be done. You can prioritize backlogs of tasks using tools like JIRA or Pivotal Tracker, or Zoho, or there’s a number of different options out there. We use JIRA on a regular basis, but there’s more than one way to solve that particular problem. There should be boundaries, once again getting back to– if everything that you’ve asked for is like, “Oh yeah. We can make that happen.” Probably not. That’s not going to happen and everybody’s going to walk away from the experience unhappy. The goal is to stay on task and on budget. The sky is always the limit until you run out of funding or time. So it’s good to know when something is actually complete.|
|S2 24:38||So during the definition phase, if things start kind of going a little bit wonky, concentrate on why, and be descriptive in articulating your needs, not descriptive. Understanding what the underlying needs for features are, and making sure that that’s being communicated to the vendor. So sometimes, the feature is a must have because it’s really important to your users. Sometimes a feature is– a must have is needed because a board member won’t fund the project without it. Both are valid in being open about why it is important because that gives context. And especially if you start getting pushed back about, why this is not a good idea, it’s good to have that context and return [inaudible] sometimes the business overrides– can and should override some of the technical concerns. It’s important to strike a balance between being prescriptive and descriptive when defining requirements.|
|S2 25:36||So to get into that a little bit deeper, prescriptive requirements are explicit rules for describing what and how something is being built, which has no room for interpretation. So I expect that it’s going to be built with this exact tool. It’s going to be done using this technique. It’s going to have exactly this output, and it’s kind of like describing things to a computer. Computers are very literal. They will do exactly what you tell them to, and they will do it very, very quickly. If you tell them, similar to a genie, what you ask for, what the end result, like if you say, “I want to come into a large amount of money” and then a family member dies and you receive an inheritance, you got the intended result, but the how you got there isn’t exactly what you meant. And a practical example of this was having a requirement of a flexible layout on the front page of a site. It’s pretty standard. But there was a hard prescriptive requirement not to use panels, which is a Drupal system for performing– at the time, it was an industry standard layout tool. The justification was that, “Oh, yeah, performance is bad, but even despite having proper configuration in caching, those performance concerns can be mitigated. Logic wasn’t really entering into the conversation, and that was incredibly frustrating. Instead, we were forced by an outside organization to reinvent a system that already existed, but without the advantages of having a massive, open source collaboration and peer review and years of test cases and working on it across thousands of [sites?]. So we created a solution. We did what was asked. We conformed to those prescriptive requirements, but it was an intense, immense piece of technical [inaudible]. It took months to implement. It was kind of buggy. In some ways, it’s kind of a crystal castle, not a lot of people wanted to touch that code because it was just a– it was pretty gnarly. It worked. It solved their use cases. It’s being used today to program their front page, but that’s not the way that we would have preferred to do it. And in hindsight, another organization that was working on a similar project, hit the same wall and said, “No,” and just refused and went ahead and used panels and got that feature out faster and, upon demonstrating it, stakeholders were happy. The takeaway from that is prescriptive requirements can cause problems and you can be shooting yourself in the foot if you get a little bit too hard.|
|S2 28:27||So, the opposite of that is a descriptive requirement, which describes the characteristics of what’s being built. Notice it’s not really defining how. It answers the questions about what, when, and why. So it could be incredibly descriptive and there can be hard requirements, like it must conform to these specifications. But there’s a level of trust that’s required. The requester relies on the experience and the judgments of the implementers, the people who are actually doing the work, and the people who are doing the work rely on the quality of the description. If you have a coherent description, if you say, “I have these expectations around it. This is how it should be working, and this is the use-case that it has,” then hopefully the engineer has everything that they need. And if there’s any questions that they can reach out for clarification. And at the end of the day, if you’ve entered in a relationship with a consultant or an outside team in order to achieve the solution, it’s because you’re looking for help and that might not be available internally, either due to budgetary reasons or just skill sets, or just you don’t have the time. I mean there’s all sorts of different reasons why you reach out. Trust those who are helping you. And then you also– and they need to trust that the information that you are giving them is sufficient in order to complete their tasks.|
|S2 30:03||So, as many things in life, the truth and reality is somewhere kind of in the middle. Prescriptive requirements, sometimes, are necessary, especially when working with a junior developer. Some people strive structure and need explicit steps. With that said, if the requirements are too prescriptive and inflexible, then you can easily end up with a system that’s exactly what was requested, but what was not actually needed. So, striking a balance between the right level of design in architecture, it can be kind of tricky. It’s easy to spend too much time planning out features and running through endless revisions and it’s just as damaging to spend too little time designing and architecting and ending up eating some of the development time. So a good design and architecture phase, you have a vision that’s like a good story with a beginning, middle, and an end. The innovation is driven by the business needs, not the other way around. Don’t expect to have– if you’re coming out of an– if you’re migrating from an existing system, don’t expect to have 100% feature parity. There’s a reason you’re moving out of it. It could be clunky. There may be good features and that might be worth replicating, but don’t try to have a perfect carbon copy because a copy is a copy. Usually something’s lost in the process and the edges get a little fuzzy and it gets gnarly. Make sure that there is a– any type of design in architecture that exists should be influenced by user research. That can be as simple as walking a mile in my shoes, actually using the interface, watching other people doing it, performing studies with a group of users, talking to power users and so forth. Each decision should map to addressing a particular need. Why do we need this thing? Because it addresses this particular need. Oh, okay that makes sense. The design in architecture should be advocating for the right degree of design and it should reflect a plan that reasonably addresses both the current and future needs. We can’t possibly anticipate every particular variation or need, but there can be some things that you can make reasonable assumptions for, like plan for possibly 20% more traffic than you get today, but planning for 2,000% more traffic than you get today unless you have an explicit triggering event, or a phone call in the middle of a presentation without silencing your– yep, oops. That’s embarrassing.|
|S2 32:56||Anyway, so the goal should be not to under or over engineer a solution, it should be sufficient for the task, it should be able to handle the capacity of everything that you know about to date and then [some?], and making sure that at the end of the day the goal is to deliver value, not just clever code. Just because it’s something shiny, just because it’s something that you heard about at a conference or looks great on a paper or on Hacker News doesn’t mean that it’s necessarily the best fit for your project. So use the right tools and for success.|
|S2 33:41||So ways to check whether or not something is working well. There should be a schedule, and you should be sticking to that schedule. If you need to spend more time in design to move the launch date, and if you can’t move the launch date, stick to the schedule. I mean this sounds a bit pedantic, but there’s meaning behind it. I mean this part is where it’s very, very easy for a project to take a lot longer than expected. If you go through countless iterations of design and going back and forth or start like shedding and hyper-fixating on like one particular area, it’s like you can’t see the forest from the trees, and the goal should be to ship a coherent product.|
|S2 34:21||So ways to check to see whether or not something’s going well during the build phase. The system works, and it keeps working, and you know how much is left to work on. So you always have an understanding of what the status of the current build is. Is it something that you can actually use and play with, things that are working shouldn’t stop working suddenly. If you have a process that has built-in tests that are checking for key functionality, that’s one way to mitigate that, but also having just kind of like user testing and saying, “Okay, yeah.” Every once in a while it’s like, “Yeah, let’s go look at, I don’t know, a map feature,” and halfway through it’s like, “We implemented that early on, let’s make sure the map still works.” Make sure that the end users have the ability to actually access the system. Don’t wait until the last minute to do this grand unveiling and then people will get a nasty surprise if they haven’t been involved or feel like, well, this is completely out of our control, or now I have to be forced to use this thing that I had no input on, or just straight up this doesn’t meet my expectations, and this is the first time that I’m seeing it not invented here and so forth. During the builds, you should have kind of a stable staff that is going to be working on the project and that they understand what’s going on. People can come and go on a project, but having at least a core group that are going to be focusing on the implementation is important because you build that institutional knowledge and it aids in onboarding and so forth. So if you hear that kind of, “We’re going to catch it in QA” or “We’re going to harden the project,” after launch or prior to launch. If you’ve ever done media production and you hear the term, “We’ll fix it in post,” it’s the same kind of thing. Garbage in, garbage out. If you don’t have something good up front, trying to polish it later, you can end up with something that’s shiny, but is it really what you needed or wanted?|
|S2 36:46||So during the build phase, what you can do, honestly, most of it is being available for questions, and making sure that you’re involved in the process, that you’re paying attention. Hold people accountable. If this isn’t what it– if you start trying to use the system and you said, “Okay, it needs to be green,” and you’re looking at it and it’s like, “This is very clearly yellow or blue or orange,” or what have you, it’s not meeting your expectations. Don’t just say– don’t just assume that it’ll get taken care of. Raise it as a concern. It’s okay to reject something if it doesn’t meet those expectations.|
|S2 37:27||So at the end of the day, agile methodology is something that is thrown about [laughter] and say, it’s like, “Oh, yes we’re agile,” but what does it actually mean when you’re building a product? And this gets back to what a minimal viable product is. So the top row. You see– we’re trying to build a car. Okay. Cool. So first phase, we’ve got a wheel. This is not what I want. Second phase, we’ve got a wheel with a chassis. Well, great. Third phase, we’ve got a wheel, a chassis, and a body and then I’m still not happy, but finally, I get something that looks like a car. Cool, this is what I asked for. That’s not agile. That’s just building something, and part of the unhappiness is it’s not something you can use; it’s not something that you can actually interact with. And instead an agile process will have iteration in which the first time it’s like, okay, well you need a mode of transportation. Instead of having a prescriptor requirement here’s a descriptive requirement. I need to be able to get from point A to point B. So, here’s a skateboard. That’s not really what I wanted. Okay, fine. Here’s a skateboard with handlebars so I can actually control which way it’s going because I’m not really comfortable with leaning. Oh, all right. That’s cool. Still needs a little bit more to go. How about a form of propulsion? Great. All right. A bicycle: human powered, fantastic for the environment, and I’m enjoying this a little bit more. Okay, but I want to go faster. I want to be able to go on highways. Motorcycle: obvious iteration, absolutely fantastic. I love being in the open and getting from point A to point B. But I want to able to carry a bunch of cargo, but I still like being exposed. All right, I’m super-happy now that I’m in a convertible, because that conforms to all the requirements that I have that a mode of transportation be able to hold my gear. I discovered that I actually really like being out in the open, so having no top is perfect. And the outcome can be similar. But here’s this regular sedan versus a convertible, but the differences are; you’re much happier with the convertible because it met all your needs and things that you hadn’t anticipated early on.|
|S3 40:04||Awesome. So let’s say that it’s not going well. What are the things that– how do you potentially turn things around? And how do you answer the first question that comes to mind: is it the vendor or is it me? Is there something wrong with my organization? The answer, honestly, it’s almost always both, and it’s almost always due to a lack of communication on some level. So that other means that you and the vendor can speak in a different language, talking about different things that sound like they’re the same, but really are very different requirements and needs. And also that either party is reading into the things that the other is saying without being explicit. The other thing that happens is that somebody’s not being honest, either with themselves or with the other party. A lot of times that can be a vendor who’s trying to work on internal staffing problems, or it’s because there’s an organization who hasn’t really identified who the stakeholders are, and there are executives who swoop in and make last minute changes to scope and what’s actually important. Regardless of where you can sort of point or a place to blame, the best thing to do is to try to turn things around, and early on when there are warning signs or things that are making you uncomfortable, and kind of talk a little bit about that process about how to turn things around.|
|S3 41:57||We’re going to– what you really want to do is look for a quick win. Don’t let problems linger. If, in Jon’s example, if something’s blue and it’s supposed to be red, engage that. Try to get it fixed. Don’t take, “We’ll fix that in QA” as an answer. Spend some time trying to identify the root cause of the problem. A lot of times, both internally here at Four Kitchens, or on a client project, the first step to fixing a problem is to have a [retro?], where everybody gets into a room together and talks about what went well, what didn’t go well, and what we need to change to make things go better. Just answering those three questions, in an open and honest way, a lot of times will be able to turn things around. The next step is to really reset expectations. Don’t take your baggage from things not going well. Get into the process of trying to make those things better. It’s kind of the same idea in a relationship: don’t go to bed angry. It’s an important step in being able to actually move things around– change things for the better. Taking the time to reflect and [retro?], as I mentioned, is an important part of this process. And then work together to form short term goals. So understanding a place where you and the vendor can win together. And a lot of times this happens in sort of– in the guise of a contract renegotiation, or a recent meeting of expectations. But a lot of times really what’s needed is just a conversation about what went wrong, how do we make it better, and how do you– and setting mutually agreed upon and fast expectations. Finally, hold them accountable. If those expectations are not met, escalate the issue. And don’t just let things, again, kind of fall back into the doldrums of not going well. But the important part here is to build on the success that you can form together. It’s a lot easier to build on successes than it is to continually try to fix problems. So really the goal should be in trying to– if you’re trying to turn something around, it should be for finding a success that the team can share.|
|S3 44:55||Thanks [laughter]. So next, I just wanted to go through some of the, kind of the most important things that you can do to make a project successful when working with an outside vendor. The number one thing, both Jon and I have mentioned it throughout the day here, is to hold them accountable. And, to be clear about what your expectations are. The next is to try to understand their motivations and try to be very clear about yours. A lot of times this can be difficult to understand your own organization’s motivations and the power structures within can sometimes be a big part of making a project successful or what separates the experienced leaders from those kind of just getting started. Ensure that your stakeholders have the attention and time to make that project successful. Many times, we work on projects with large organizations and they’re high-value projects for an organization. And the executives who already have a full workload are our primary contact. That will usually lead to that person being overworked and not being able to provide the level of attention that’s needed. So, delegate if you have to, or move other responsibilities, but if the project is really important for your organization, it deserves your time. And then, finally, be professional and expect the same. Getting emotional in a business setting doesn’t really help people. It doesn’t really move things forward. So, keep it civil. Sometimes that takes work, but I can guarantee you that it’s always going to produce a better result.|
|S2 47:13||Yeah, at the end of the day, having the perspective that, we’re all on the same team. We maybe have different email addresses, but we’re all working on the same product. We all have the same goal, which is to achieve success. And make it a collaborative conversation, not an us versus them. And that type of positivity and relationship building is essential to the success of any project.|
About Mike Minecki
Mike is a developer who dabbles in management; he’s the Director of Technology at Four Kitchens.
About Jon Peck
Jon is a senior engineer focused on backend architecture, optimization and performance. Originally from Upstate New York, Jon currently lives in Castro Valley, California.