Tag: best practices

  • Payment Strategies – Finding a Comfortable Time Frame For You And Customers

    Payment Strategies – Finding a Comfortable Time Frame For You And Customers

    One of the challenges all consultants face is setting up payment strategies for their customers. There is a need to keep revenue flowing while providing a reasonable amount of time for processing invoices. That is not as much a problem when there are multiple customers and they pay regularly. However, it can be crippling to a business when bill payments (or payroll) are delayed due to accounts receivable (AR) issues. A small company or individual consultant can struggle with this. Thus, it is worth our time to examine some options.

    Not One Size Fits All

    Note that the discussion is on strategies and not a single strategy. I have found this to be one of the first steps in meeting your needs and your customers’ needs. One way to slice up the approaches is based on your trust or experience with customers. This approach provides more grace in payments to your established customers while limiting risk for newer ones. Payments terms can be based on AR age or AR total. Both of these are easy enough to track for even a small company and can be set in contract requirements.

    I find that both approaches are helpful in small consulting companies. Some projects generate minimal revenue month over month. That can lead to small receivables sitting on the books for several months. At the other extreme, large revenue items can be critical to cash flow. When they are not received on time, the business can struggle. That latter situation is often a challenge for small consulting companies or individuals due to the feast or famine nature of this business.

    Payment Strategies Based on Trust

    Trust of customers and their payment processes is most effective when it is based on past experience. Therefore, it is best to start all new customers with a tighter set of rules and then loosen them after they have gone through multiple pay cycles. I recommend a minimum of three complete cycles. One or two is too easy to be an aberration or just them trying to keep new accounts current. Then, as you see consistent invoice and payment cycles, you can adjust your requirements to fit cash flow needs.

    Cash Flow Is King

    We all want to sign contracts and get those billable hours flowing. However, we need to see the payments for those hours flowing as well. When planning payment strategies, you need to be aware of your business’s monthly budget/payables and related payment terms. There is often a delay of 30 days or more from invoice to first payment, which can cause challenges if you do not have reliable cash reserves. Take note of your bank’s deposit hold terms as well. Receiving a payment is not the same as those funds being available. That may seem minor. However, we can see fewer and larger deposits for some customers that trigger the hold rules. I have often seen this pop up when a customer delays a few payments and then catches up in one big check.

    Splitting Invoices And Pre-Payments

    Many companies are hesitant to be aggressive with payment strategies when they start. Therefore, they set and accept customer-friendly terms but can lead to struggles as the business gets off the ground. Nevertheless, it is easier to reduce restrictions and policies than add them. Therefore, the best time to take a hard-line stance is when you start a customer relationship.

    Multiple invoices and early invoicing can help with this. Some companies invoice immediately on receiving a signed contract. That can cut down the time to payment by weeks or more. Likewise, it is more acceptable to pre-invoice some portion of the project or request a fee to start work. This strategy reduces risk and ensures you have some cash flow from the time the project begins. It may not solve all the problems, but it is an excellent first step.

  • The Shortest Path To Solve A Problem

    The Shortest Path To Solve A Problem

    Velocity and speed come in two ways. You can increase power, or you can reduce drag. We can find ways to address both of these aspects to solve a problem faster. Some of these may be obvious. However, I often find many to be overlooked regularly. That may come from rushing through the process or even institutional and cultural limits.

    More Than One Way To Solve A Problem

    Most problems have multiple solutions. Likewise, some are going to be better than others. Therefore, do not let perfect be the enemy of good. The first solution is at least a solution. That is more than you started with. That may be all that is needed. A better solution may be the goal—however, version 1.0 of a solution is better than nothing at all. There is also the option to build on that first solution. When you keep going back to the drawing board, you limit what you start with. Sometimes getting close to a solution provides a foundation or watershed moment. When that happens, you can start the next effort closer to the end. It is like climbing a mountain in stages instead of one herculean effort.

    Remove Drag

    We can start by removing drag on our problem-solving approach. However, let’s first think about what drag is. It is anything that causes friction or otherwise slows down an object or process. That includes things that may take the progress off course. For example, a river may re-route itself if something causes enough drag. Likewise, your GPS may re-route you if there is too much friction in the form of a traffic jam or accident. Now indirect progress may not exactly be a drag, but it works for our purposes.

    The biggest drag I have found in all my years of work to solve a problem (big or small) is misdirection. That may come in the form of going down the wrong path or even solving the wrong problem. The simplest example of this is trial-and-error. Every error (wrong path) slows your speed to a solution. The sooner you get on the right path, the quicker the problem is solved. That brings us to our first key point.

    Ensure You Have The Correct Problem

    That may appear to be an obvious starting point. Nevertheless, it is a common mistake. Humans are known for confusing cause and effect. Likewise, we all have moments of focusing on the wrong aspect of a situation missing the root cause. We sometimes even solve a problem that does not exist. We assume trends where there are none. Start your process by stepping back and examining how the problem arose or manifested. It is easy to get off track and lose a lot of time chasing after requirements that are not needed. When possible, ensure you can reproduce the problem/error. Then, verify the solution actually addresses it.

    A tangent struggle to this is assigning blame. There are many times blae is chased down first. However, that does not solve the problem in most cases. Therefore, work on the problem first, then worry about heads rolling. Reviewing why a problem occurs or occurred can have limited use. Rather than focus on what happened, keep the focus on how to avoid it in the future.

    Fail Fast Fallacy

    The idea of failing fast is popular among some circles. That often is used as a way to remove analysis and push to try things out. Yes, trial-and-error can be useful. However, random is not as good as a focused approach. We have to find a balance between quickly verifying potential options and overthinking their value. We are not going to increase velocity to solve a problem by quickly removing options unless they were valid in the first place. Each successive failure should be methodically moving us toward the solution. Thus, we can think of it as a mortar fire walking in the charges to the target. There will be attempts that take us away from a solution, but that means we go back and try another direction.

    The Single Step

    The is an old saying that a journey of a thousand miles starts with a single step. That is true every step of the way. We can think about a problem and discuss it, and even rehash it. However, we are not going to make progress on a solution until we start work on that. There is a time to think and time to act. Make sure you understand what time it is and you will get to that solution faster. You might even reach it faster than you thought.

  • Building a Code Review Culture

    Building a Code Review Culture

    I was recently in a conversation about software development and asked about my thoughts on doing a code review. The assumption was that a code review is a good thing. However, there was a question as to how they can be done properly. It may sound like a cliche, but that is an excellent question. There are billions of lines of code written each year, from scripts to full-featured languages. We need to be aware of how to write and produce better code. The review process helps us do that.

    What Is A Code Review?

    We should start with the goals of this practice. Of course, companies vary in their official objectives. Nevertheless, code reviews almost always have the same list of goals.

    • Reduce bugs
    • Improve Quality
    • Verify Adherence to Standards
    • Cross-training/Leverage Expertise

    There are nuances and details to each of these items. However, a process that addresses these is off to an excellent start. We should not do anything simply to be busy or conform to a norm. We want to have concrete value in our work, and the above items give us that.

    Developer peers typically do a code review. There can be any number of participants, and it may be direct and in-person or performed off-line. There are tools to assist in a review, or “paper and pencil” approaches might be used. The highest level description of a code review is a person (or persons) walking through source code with an eye for improvement or errors. We can look to the above objectives to help us flesh out this process to make it more effective.

    Reduce Bugs

    It is frustrating to developers, but many bugs are easy to detect. There are typos and simple logic flaws we miss while cranking out code. The second set of eyes can often help us quickly spot these issues and address them. A code review that aims to assess logic and scan for inconstancies can help us squash bugs sooner and faster. This is not a process without cost. It takes an investment of time to review code and provide feedback. However, it is worth the effort. We gain in quality but also productivity as we work together to implement solutions that are peer-reviewed. The things I am most attuned to are not the same as your experience. That means a few minutes of your time may easily determine bugs that take me hours to track down. Minutes for hours is always a worthwhile trade.

    Improve Quality

    Quality and bugs are related but not the same. You can write low-quality code that is bug-free. Yes, I mean that. There is a lot that goes into quality. It has to be correct, maintainable, scalable, stable, and more. A code review helps bring the team to the same page. The programming standards can be reviewed and feedback given on specific code rather than just functionality. That leads to better developers, tighter code, and a consistent style throughout the application that makes it much easier to maintain. You get a reward today and in the future for going through this process.

    Adherence To Standards

    Every organization needs a standards cop. There is value in everyone on the team rowing in the same direction. This objective is partially addressed by standards. While there are automation tools that enforce these rules, not everything can be reduced to a rule. The code review process allows the team to go over processes and standards with an eye towards to enforcing and improving them. It is easy to take a short cut in a rush to solve a problem or forget to “clean up” a quick code snippet. That is where this process comes in. The author has someone to follow behind and provide accountability for the work before it is committed up the chain.

    Cross Training

    Another benefit of going through this effort is cross-training. Team members are at least exposed to areas they may otherwise never see. There is always a cost to cross-training in terms of time. However, a code review adds value immediately while still moving forward the breadth of experience in the team. Members that are completely ignorant of a section of the solution can gain insight and even familiarity through this process. They not only see code, they are brought into the discussion as features are created, bugs found, and decisions made. They also have a context to work with in terms of code that has been reviewed in the past.

    A Worthy Investment

    My goal through all of this is to show that there is value in doing code reviews. However, it is not something you can magically start and immediately do fully. There is an art to being able to walk through code and provide insight. That takes time and experience. Therefore, the best time to start this process was last year, but the second best time is now. Get out there and bring the team into your coding.