Tag: best practices

  • The Value Of Demos and Walk-Throughs

    The Value Of Demos and Walk-Throughs

    One of the most challenging facets of building software is determining where to spend our time. Demos and walk-throughs are one of those areas that can be overlooked in the chase to save time. However, they are essential in communicating progress and gathering feedback. These require time and attention from everyone on the team, so let’s look at ways to ensure we get the most out of this investment.

    Demos and Walk-Throughs Are Not Optional

    We can start by agreeing that every project requires this activity at least once. While one can build a solution and “throw it over the wall” to the customer, I do not know anyone who accepts that approach. There are too many details, and custom software is too expensive. No one buys a house without a walk-through, and software should not be any different. A big cost equals a big investment. Therefore, we want to review the results before signing off on them. That can be accomplished without a demo, but it can be time-consuming and confusing to jump into a system and try to use it. We need context to help us assess a solution, and that is where demos and walk-throughs fit into the process.

    Your Definition, My Words

    An excellent way to be clear when we are communicating is to have someone say back to us what we told them but in their words. The same exercise can be done through a walk-through of a solution. The project starts with requirements and a solution specification to ensure everyone is on the same page. However, there can be design drift and miscommunicated goals that cause a solution to vary from the specification in subtle yet critical ways. A demo helps us detect drift sooner and possibly avoid these issues. At the very least, this helps us reduce the cost of correcting drift. The implementors explain how the solution works while showing it in action. That provides a perfect starting point for concrete discussions and feedback about the solution.

    Assumptions and Details

    When we describe a process or problem, it is easy to incorporate assumptions and gloss over details. For example, think about explaining how to tie a shoe. Write down the steps you need to take and then follow them explicitly. Most people will fail to tie their shoes. The details and assumptions hidden in the process steps do not become apparent until you test the steps by applying them.

    Modern software is highly complex and detailed. Thus, we need to test the steps and requirements we start with through regular demos and walk-throughs that explicitly follow the implemented solution. This provides us more confidence with each successful journey through a feature while also making it easy to see exactly what is being built. That reduces confusion and invites feedback to correct any drift or misunderstandings. The cost-savings and improvement of the success rate from these activities alone make them essential in any project.

    Trust and Teamwork

    The above reasons should be enough to convince anyone that demos and walk-throughs must be a part of every project. However, many more benefits come out of those meetings. The most valuable of them are trust and teamwork. A demo that includes feedback and discussion is, almost by definition, teamwork. The participants work together toward a common goal. These interactions also build trust and relationships that are essential for a strong team. Projects often hit rough patches and introduce stress into the team dynamic. When we have trust and solid relationships, these bumpy periods are easier to navigate. A lack of trust in any group or relationship will almost always make the hard times harder.

    Transparency

    We get a form of transparency as well as clarity through regular demos. The progress made and how it looks is available to all via these meetings, and that drives dialog which drives understanding. However, these benefits are not a given. Here are some things that need to be a part of the agenda to make the best use of this investment in time.

    • Have an agenda. This seems redundant, but every demo should have a plan. We want to ensure good discussion and avoid too much time spent on distractions or minor features.
    • Include regular set-asides for Q&A. Make it clear that feedback and discussion are a part of the plan and schedule time for it.
    • Provide a reason or story. A good solution will point back to the requirements and the problem definition. Each demo should be a step in the story from the whiteboard to solving the problem as defined at the beginning of the project.
    • Include more action and fewer screenshots in a demo. There should be almost no “talking through” steps and instead show the steps with inputs and outputs. This avoids possible confusion and ensures the resulting solution is a reality rather than smoke and mirrors.
    • Provide for an expanded discussion where needed. Some problems and challenges can take a lot of time to work through. A demo highlighting an issue should not be ignored or discussion constrained. Instead, provide a platform for full discussion and the best decisions to be made.
    • Avoid the firehose approach. Sometimes a lot of progress is made from one demo to the next. That can lead to information overload. Set the pace and volume of a demo so the audience can digest what they are seeing and provide timely feedback. A demo that is overwhelming in scope is more likely to miss details through sheer overwhelm.

    Remember The “Why”

    There are many benefits to these investments of time. However, we need to ensure we keep the reason for them in mind. Our goal is to show off progress and gather feedback. Thus, when we forget to make these a part of each meeting, we fall short of our goal. That limits our ROI and increases our chances for mistakes and even failure. Avoid this misstep and keep the team focused on what is expected of each meeting. The Agile Manifesto says it best when it points to the utmost goal of software should be to satisfy the customer. Use these tools to help ensure that remains the primary goal.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. Every project we work on includes demos and similar discussionns on a regular basis. Often every two weeks and those include a release our customers can use to further test the features and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects. 

    Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will 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.

  • Investing In Requirements

    Investing In Requirements

    Custom software can be very expensive and scary, but investing in requirements can help you improve the likelihood of success. However, we often want to see things being built rather than simply think about them. That creates two things that fight against each other (get it done or think it through) in many projects. Thus, we must consider early work on requirements and design as an investment. We pay for it in patience, but it saves us in almost every way down the road.

    Investing In Requirements Is An Easy Choice

    There is so much value in thorough requirements gathering that it seems impossible for anyone to pass over this crucial step. Unfortunately, it is a common problem and one of the reasons many software projects fail. Yes, we want to see “work getting done,” but the only reason that is a problem is because we are not yet seeing the end product. I like to use the analogy of going on a road trip. You are not getting closer to the destination until you start driving. However, if you do not know where you are going or the obstacles on the way, it can be extremely costly. Those that use modern GPS maps or apps like Wayz often are redirected around problem areas and potentially save hours of drive time. That is the same with software development. We are not writing code but investing in requirements, so we have a better idea of the path ahead. That allows for proper estimates and planning.

    We Can Adjust As We go

    One argument we fall prey to is that we can start building the software and easily adjust as we go. While there is truth in that, and we do not need to know the whole journey in detail, we do need to plan for each stretch. That is what the Agile approach embraces. It takes a bit from both worlds and gets us on the road faster while still ensuring we are planning enough to avoid major issues. When we use the road trip analogy, it is like planning the trip but then being open to adjusting due to construction or traffic delays. However, the key is that we need to know at least some of our path before we start. In a software project, this can be done via high-level requirements and core feature definition. Be warned that is a possible approach, but it can still suffer from wrong turns and proceeding down dead ends.

    Back On The Main Road

    The discussion of Agile and its strengths and weaknesses is for another article. Let us return to a focus on requirements that applies to any software project. Modern software systems are highly complex. There are tools that can help us to create or generate thousands of lines of code quickly. However, that speed can be just a faster way to create a big mess. I have seen many projects stumble and fall due to this issue. The problem may seem simple, but the details are highly complex.

    For example, let’s consider the simplest of problems to solve: keeping contact information for your customers so you can serve them. How hard can it be? There is a name and address and maybe a phone number or email. Oh wait, what if the customer needs a title, or is a company with multiple contacts? What if the billing contact is different from the key decision maker? Do we care if they have bought from us before, or do we track leads? Should we keep notes each time we talk to them? The list goes on and on. A simple problem can quickly become a complex maze of decisions. These can be very costly to make if we have already made a lot of progress on our software journey. Changes can require updates to code the database, the user interface, and even the partners or libraries utilized. Backing up is far more than that BEEP, BEEP, BEEP a large vehicle makes.

    How Do We Get The Requirements We Need?

    Custom software development is just a way to solve problems on a big scale. Thus, we can use basic problem-solving techniques to guide us in creating a list of requirements that we can be confident in. Here is a short list of questions that you can use to take your requirements definition up to another level.

    • What does this need to do?
    • What does success look like?
    • Who needs to know about task completion?
    • Where can it fail?
    • Who needs to know about a failure, or how do they need to be told?
    • Is there anything else it needs to do?
    • Can any user do it?
    • Does every user experience it the same way?
    • What did we forget?
    • No, really, what else did we forget is a part of this process. Walk through each step as thoroughly as possible.

    The above question may not seem like much. However, they are easy to overlook. I have worked on dozens (probably hundreds) of software projects and still need to step back and review these questions each time. We can easily get lost down a rabbit trail and skip a step. A thorough review before building out requirements is a huge step in the right direction.

    Play It Back To Me

    A good way to ensure clear communication is to have someone repeat back to you what you said in their words. Do the same thing with your requirements. Walk through your problem and the proposed solution using only what is listed in the requirements. This action often brings up more requirements and details than even the last two questions listed above.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. We are happy to help you with investing in requirements and improving the overall success rate of software projects. Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will 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.

  • Solving Business Problems, Not An Experiment With The Latest Tech

    Solving Business Problems, Not An Experiment With The Latest Tech

    The modern landscape makes solving business problems an exercise in finding the right provider most of the time. In my experience, software consultants and solutions providers come in three types. Some are heavily invested in existing technology and want to use that for every customer. Then, some want to jump on every new technology and use clients as guinea pigs. The third type focuses on the client and the best solution. Once that solution is defined, they decide how to implement it. These are the ones you want for your project. The challenge is figuring out how to weed through the options.

    Solving Business Problems Is The Focus

    I would say start with the website or proposal. However, you might come across a provider that does not have a website and has not sent you a meaningful proposal. Those are easy to ignore. It is hard to take a technology business seriously that either does not have a website or that has one that looks like it was built by a child a few decades ago. Here are some things a good provider will have on their website. The more of these, the better, and the more details, the better.

    • They talk about successful projects and solutions rather than technology stacks.
    • There are multiple clients represented, whether across projects or stories.
    • The focus is on problems they can solve as opposed to buzzwords.
    • Your non-technical friends, family, and coworkers can understand what they do without searching for the meaning of several terms.
    • There is a start and finish to the projects they highlight.

    While all of the above items are not required, a complete lack of this sort of content should raise warning flags. The alternatives you might see will list a bunch of technology they use (the stack) or provide links to cutting-edge vendors. They likely have the wrong focus when the site looks like an article from a tech news site or program.

    Finding That Perfect Match

    Once you have whittled down your list of prospective providers to those that actually solve problems, your next step is finding a match. The best providers will talk about solving problems you have faced or need to solve. For example, a vendor that spends a lot of time discussing how to market your business may not be the best if you need to track sales or integrate systems. On the other hand, a vendor that talks about bringing customers to your website may be the perfect fit.

    Be Prepared

    This may make you wonder how to match your problem to their skills. That is a good question and does require you to start by ensuring you have correctly understood and defined it. That is a mistake many companies make. They look for a provider and expect the provider to help define the problem and then provide a solution. While that is an acceptable approach, it will likely be more expensive. You will end up in a situation where you are in that old description of paying a consultant to use your watch to tell you what time it is. They are going to be an essential part of crafting a solution. However, you will want to invest the time in defining your problem to solve and related requirements as much as possible.

    A software project can be an expensive process. Think of it like a house or a mansion. You would not go into one of those projects blind or without firm ideas of what to expect. Do the same with your business. Take the time to examine your processes and the pain points you want to reduce or resolve.

    Next Steps

    We have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will 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.