Tag: team building

  • How Do I Find An IT Solution?

    How Do I Find An IT Solution?

    This post starts a series to walk one through the questions we must answer in finding solutions for business problems. We will focus on IT solutions because so many challenges are best solved through automation. That is where software applications shine. However, there will be situations where your best solution is not found in IT. You will find a path to those other solutions when you answer the questions we explore.

    Start Here

    You can spend a lot of money on software consultants and solution providers. They may or may not guide you to the best solution. Therefore, this free list of questions may be the best investment of your time. It would be best to answer these questions, or at least be aware of them, as you research what works best for you.

    Before continuing, note that the best solution requires investing time and money. A good consultant or provider can guide you, but they must learn how your business works. This is not a summary or overview but will be in-depth. Think of it as building a house. You do not simply say, “I want a house with X bedrooms and Y baths,” there is far more detail you provide. A good business solution is no less complicated. The details will help you find an IT solution that fits you like a custom-tailored suit.

    My Checklist of Questions

    Let’s start with those questions we need to ask. We will explore them in more depth in this and upcoming posts.

    What Is The Problem You Want To Solve?

    This question appears evident at first glance. However, it is often skipped over or not provided the thought it deserves. The challenge in answering this question is to solve a problem and not one of the symptoms. Think of a doctor that treats a fever instead of curing a disease. Unfortunately, that is often what we do in business, particularly in software. An excellent way to approach this is to return to your childhood and ask “why” until you reach the root desire. It is incredible how often this provides not only a better solution but also a far simpler implementation.

    An Example Problem To Solve

    I think an example works best for this aspect. We can start with a customer that wants to be able to copy data from one application to another. The goal is to open application A, do a sort of screen print of data and then be able to paste the data into application B. Awesome, now ask why. They want to paste because they have orders entered into one system and then need to put that data into a fulfillment system. This situation is not uncommon. Multiple systems and data need to flow from one to another.

    Rethink Your Process

    We have a few jumping-off points. However, we will focus on the back end. What happens with the fulfillment system? Why enter data in that? The answer is that the order is printed out and handed to the warehouse for pick and shipping. The shipping information is printed and sent to someone to enter into the fulfillment application. Then, they repeat the process with application A. Then, an order is marked fulfilled, and data is entered into system A to show it was shipped. We can see where there are duplicate entry points and the opportunity for data entry errors. Fortunately, it is not uncommon for us to see a system’s flaws when we walk through it step-by-step. While some organizations require printed forms and data, that is becoming rare. Instead, the case is often that “we always did it that way,” and the challenge is changing rather than a business need. However, you can find an IT solution with less cost than you think.

    Find The Right Perspective

    The example also provides an error in perspective. Too often, we focus on a single problem or pain point and fail to step back and analyze how we got there. In the above case, the problem is not getting data from system A to system B. Instead, it is getting data from a customer through shipping, invoicing, and fulfillment. Software projects can struggle due to a change in scope or focus. The original problem is shown to be insufficient once the project starts. That can lead to many challenges we can avoid by starting with a better handle on our final goal. Instead, we find an IT solution before knowing how to solve the problem correctly.

    The First Question To Answer

    Any successful journey has a starting point and a destination. Every project is the same way. We will improve our chances for success substantially by assessing where we are and where we want to go. Therefore, you must first answer, “What is the problem you want to solve?” There is no need to find an IT solution until you have that answer. While there are consultants that can help you refine your answer or answers, you will be hard-pressed to find the best resources or approach until you have a solid solution to start with. We are available to help you in your journey. However, you can often do yourself a huge favor by asking yourself, “why?” a few more times before you search for someone to solve your problem.

    Improve Software Success

    We have an e-book that can help you explore all the steps in building software, including a few templates. All we ask is that you share an e-mail address so we can send you a copy. We will also add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.

  • 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.

  • Finding A Solution With Limited Resources

    Finding A Solution With Limited Resources

    We all have times and projects that are beyond the available resources.  It is a goal too big or a window too small for our limited resources.  In the world of business, this may be too many tasks and not enough team members.  In our personal lives, it may be a day full of too many tasks and not enough hours.  There are ways to work through these situations.  Fortunately, we can even get a "win" at times by embracing some of these common ways to overcome shortcomings.  These include a lack of resources or a lack of skills.

     Face The Reality of Limited Resources

    The often largest hurdle is to admit you have limited resources for your objectives.  It can be tempting to try to jam a square peg in a round hole.  That includes trying to achieve a goal even with limited resources.  This approach is not different from sticking your fingers in your years and loudly saying "I can't hear you" to avoid bad news.  It is not beneficial and amounts to ignoring the problem.  I have never seen this as a valid approach.  It blocks us from taking productive actions like those that follow.

    Some try to aim for the stars with the idea of at least reaching the moon.  However, it seems like too often, you end up flat on your face.  There has to be at least a plan for hitting that lesser (more reasonable) target.  This approach also helps avoid spending time on tasks or features that end up being unfinished or of lower quality.  

    Adjust Scope

    The easiest way to match resources to a goal is to change the goal.  That may mean accepting a solution that is only 80%.  It may mean waiting longer or spending more money.  Any of these changes may be acceptable.  However, make the hard decisions and adjust your goals.  It allows the team to focus on the new goal and ignore things that do not contribute.  In many projects, this decision can remove tasks from the board and free up time to get to a high-quality and acceptable solution.  In some cases, this will equate to highly marketable versions 1 and 2 of a product instead of a late version 1.

    Sooner Rather Than Later

    The sooner you accept that changes are needed, the better.  I have seen projects go until the figurative final hour before trying to make adjustments.  Many of those projects would have been delivered on time if only they had adjusted the course sooner.  The more time you have left in the journey, the less course correction is required.  In software, this can be a substantial factor.  Early decisions can free up resources in every area, from design and analysis through to testing and deployment.  An excellent example is the choice of platforms.  I have seen projects drop a native mobile requirement late in the game that literally could have reduced the overall cost and timeframe by half if done sooner.

    Wait For The Estimates And Accept Them

    Estimation can be time-consuming.  Nevertheless, it is precious.  Good estimates can warn you of issues in scope or timing long before they become a true obstacle.  Take the time to estimate tasks and effort.  Then, accept those estimates.  When you have estimates that put you beyond a target, adjust the target, do not push back on the estimates.  This process will create a bad environment where people provide what you want to hear instead of reality.  That can lead to the emperor having no clothes, and you are the emperor in that case.

    Working Smarter With Limited Resources

    It is almost a cliche to work smarter, not harder.  Nevertheless, there is a lot of value in this approach when you have limited resources.  We often have extra things that are done as part of a project.  These tasks include estimation, planning, administration, polishing, and other items that may not be needed.  While they may have value, they may slow you down.  We can see this in race cars.  They strip down the vehicle to only what is necessary for the race.  When you lack the resources to do it perfectly, find the ways you can cut to the core.  

    A project that requires people to give up weekends or work long weeks of overtime should also reduce scope and clutter.  That means every task and the scheduled meeting should contribute to the goal.  The time for checking off a box or making someone feel comfortable was probably passed a while back.  That includes up to a CEO that wants to check in on progress all the time.  When those check-ins start to take the team away from the goals, be honest and find a less intrusive way to keep them informed.  Likewise, if something has been going bad or taking you off track (including specific resources), then do not be afraid to make adjustments.  A bad trend is likely to continue until you make a change.

    The Shortest Path

    The bottom line is that you need to focus on the goal.  Make sure you have a clear picture of what is necessary and what is not.  Then plot the shortest route to get to the end.  Drop everything not completely necessary first.  Once the simplest path (and tasks) is defined, you can add back in things that are likely to keep you on track.  When you do this, cut deep.  It is easier and more effective to add something back in later if time permits than cut something out down the road.