Author: Rob Broadhead

  • Selecting A Software Partner

    Selecting A Software Partner

    The success or failure of a project often rides on how good a company is at selecting a software partner. Software development has become almost a commodity in many areas. However, the team you choose or build is a critical factor in project success. No two providers are the same, and minor differences can have a substantial impact. There is far more than price, experience, or even portfolios that go into selecting the best team.

    Selecting A Software Partner Is Like A Marriage

    Few, if any, people choose to marry the first potential partner they meet. Likewise, they rarely leave the decision up to first impressions. Yes, we sometimes can quickly see a bad option and reject it. However, making a selection takes time, investment, and getting to know the partner. This approach should be the same in selecting a software partner. The “home page” view of them (experience, portfolio, and pricing) should be just the beginning.

    Explore The Portfolio and Experience

    We can often start the selection process by discussing past performance. You likely want to avoid someone brand new at solving your problems (or similar ones) as well as those who have tried and failed. A good track record is not insignificant. It is just the beginning. Think of it as an icebreaker of sorts. The prospect’s history and experience are a gold mine for leading as well as open-ended questions. Get them talking about the problems they solved, the challenges they faced, and how they got through it all. These sorts of answers provide you with a wealth of information to judge whether they will be a good fit or belong on the rejection pile.

    The Goal Is A Solution

    One should always start the search for a software partner with a clear idea of the problem or problems the partner will be asked to solve. A good partner will be able to offer solutions that suit the problem. Watch out for those who talk in generalities but seem unable to provide a path to a true solution. They will give you names of frameworks or processes and technical jargon. Yet, they will not be able to phrase your problem and a proposed solution in a way that makes sense. It can be tempting to hire a partner who talks above your head because they must really know their stuff. Yes, they might know their business inside and out, but you need a partner who knows and understands your business and pain points.

    Common Mistakes and Incorrect Assumptions

    There are a few areas where a software partner selection tends to go wrong. Avoid these mistakes, and you will be more likely to find the best partner for your needs.

    • Unclear requirements – The customer should drive requirements discussions and avoid being led by what the software partner wants or their area of expertise.
    • Budget Constraints – Time, cost, and quality are the factors that combine to determine price. Your goals, budget, or schedule may need to adjust to solve the problem. A hard deadline or budget can severely limit options and what a partner can provide.
    • Due Diligence – Determining the best partner can take some time and research. Make sure it is clear what is needed and what will be provided.
    • What happens next? – A partner will likely be needed beyond deployment to enhance or maintain the solution. Be clear on that extended relationship and license or contractual agreements.
    • A Simple Solution – It may be surprising, but I have seen both the customer and the software partner guilty of underestimating the project. Critical details can often be hidden in the initial phases of a discussion.
    • Accountability – Both sides of the partnership must agree on who will do what and how to hold each other accountable. Things happen, dates slip, and scope changes. These common challenges need to be understood and an agreement reached for how to work through them.
    • Service Level Agreement (SLA) – The SLA is something that too often is left until a product is complete. Ensure the partner can step up to any desired SLA. It should be realistic. However, some partners are not staffed or built to support ongoing SLAs, such as a 24/7 support line.

    Date Around

    There are software partners of all shapes and sizes. Take the time to get to know enough that you can judge a good partner. This process is an investment of time and a critical factor in your success. Do not rush into a partnership, nor take it lightly. The time you spend finding the best software partner for you will pay off many times over.

    Next Steps

    Feel free to schedule a time to discuss your next project with us and see if we might be the perfect partner for you. We take these relationships seriously and are happy to point you in the right direction if we are not a good fit. Years of being on both sides of these relationships have taught us a lot. That initial call is free, and there are no obligations. You have nothing to lose. 

    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.

  • Clickable Demos And Wireframes

    Clickable Demos And Wireframes

    Creating software requires using tools like clickable demos and wireframes to bring a vision to life. Likewise, these tools provide a canvas upon which to refine that vision. There are many ways to make the most of these tools. Thus, we will start with a definition and then move on to how to make them work for you as a developer or a customer.

    Clickable Demos and Wireframes Defined

    These two ways to build and demonstrate software are so common it feels almost unnecessary to define them. However, we must be clear on how these tools work so we can make the most of the efforts involved. Along with effort, time is invested in these approaches, and we want them to be used as efficiently as possible. First, a wireframe is a drawing of some form or page of an application. It gives a sense of look-and-feel as well as user experience. A series of wireframes can be used to walk through a user story, much like a child’s picture book.

    Next, we have a clickable demo. This is sort of the next evolution of a wireframe. In this case, we have forms and pages that are “live” enough to click on buttons or links and navigate through to another page. The most significant difference is that wireframes tend to be more UX-focused, while the clickable demo is more about displaying flows and actions. Think of them as form (wireframes) and function (clickable demo).

    Using Them For Better Communication

    We start with the most critical outcome of these tools. They provide a way to communicate the application being built amongst technical and non-technical team members. We get to see what it will look like or at least closer to it than words on a page. Even drawn images will differ from how they look on a computer screen. These tools take us through the process of building the interface (and potentially navigation) and then provide a way to share it with others. Better yet, we end up with something people can refer to for edits and additions that are more concrete than a few sentences in a document. Those pictures are worth at least a thousand words.

    Try Before You Buy

    One effect of using clickable demos and wireframes is that users see the result in action. While it is imperfect because performance and similar issues can arise, it still shows details a vision does not. I am amazed at how often these tools lead to minor or even drastic changes to the user experience or features available. The users get a form of “try before you buy” in that they can see it working to some extent. In any case, a greater degree than a document shows.

    User Error and Developer Assumptions

    The testing portion of application development can also take a long time. There are user errors that were never conceived and developer assumptions that show up only once the solution is in use. Even regular product demonstrations can suffer from these afflictions as demos tend to be scripted and controlled. It is not the same as putting it in the hands of users. That is where a clickable demo can provide a ton of value. A user can be asked to “drive” a demo or be allowed to use it on their own time. I highly recommend this as part of any clickable demo strategy. Set it up so users can spend time with it and click around to assess it. You will be amazed by what they uncover and the feedback they provide.

    Follow The Rabbit Trails

    Happy path testing is the name for testing a system using pristine data and flawless navigation. This has its value but doesn’t do much to uncover bugs. The best testing comes when users try a different approach. Use this to your advantage while showing off a wireframe or clickable demo. You can ask several questions during the demo to chase down those details and potential bugs.

    • Is there anything missing from this process?
    • How quickly do you expect this action to respond?
    • If this action fails, how would you expect to be notified?
    • What are some ways you can see this action failing?
    • Does this make sense, or would you prefer a different path to trigger the action?
    • Is this an action someone in the room typically does? Or do we need to contact another person to serve as a subject matter expert?
    • Look closely at the data on the screen. Does it provide what you need to perform your job?

    Craft The Story

    While there are many good ways to use these tools, the best is to make your user stories come alive. These present a solution far better than even the prettiest and most detailed user stories. There is nothing wrong with them. It is just that visual examples remove a lot of ambiguity while clarifying communication. Make them a part of validating user stories and designing them in partnership with customers and users. The user stories almost become the script you walk through using the wireframes and clickable demos. If they do not match up or users get confused, you know you have changes to make.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. Every project we work on includes demos and similar discussions regularly. We build clickable demos and use wireframes as applicable to ensure the team has the best tools for discussing the solution and vision. Likewise, those include a release our customers can use to test the features further 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.

  • Minimum Viable Product (MVP), Proof-of-concept (POC), and Incremental Solutions

    Minimum Viable Product (MVP), Proof-of-concept (POC), and Incremental Solutions

    Modern software development often involves a minimum viable product (MVP), proof-of-concept (POC), or other partial or incremental solutions. These approaches embrace the reality of software being difficult and time-consuming to produce but highly valuable for the users. The tactic is a form of the Pareto principle where the focus is on getting a large amount of functionality delivered quickly. Thus, we must be intentional about building these out so they can benefit us (and our customers) now and in the future. Now, let’s start with a look at some common ways to get a portion of the problem solved and deployed quickly.

    The Minimum Viable Product

    The MVP is as close as we get to the objective of releasing a product in the shortest amount of time. The key to this approach is the word “viable” and how it applies to our product. However, It must be clear that the result of an MVP is a product that can be put in front of customers or users. That includes deployment, training, and documentation as needed. Therefore, we can also consider this a phased or versioned approach to releasing the product.

    You can also think of this as finding the solution with “just enough” functionality to be useful to the customers. Thus, this is the point where the solution is worth the money charged to customers. However, there is often a promise of some sort of follow-up features or releases that will be provided to customers. They are buying the product with an understanding that more features and functions will be coming in the “near” future.

    The Proof-Of-Concept

    A proof-of-concept is an excellent way to see what the solution to specific challenges in a project will look like. These are often functional only and not the “pretty” solution customers will see. A POC is a research project where technology and knowledge are tested to produce a solution to a new or unique problem. However, this approach also can be used to create baseline metrics for a solution. The resulting POC is far from an MPV. At this point, we are only proving that the technology exists or our design is sufficient to solve a specific problem.

    For example, a common POC category is where an integration is required. Even though the desired integration might be fully documented and a public interface, there can be critical issues that arise. A POC is the best tool for tightly defining a result so that it focuses on solving our research goal or unique problem. Thus, when we talk about “why,” the POC is a very tightly defined and specific focus that adds no bells or whistles.

    Agile and Incremental Solutions

    When one is unsure of what they really need or require rapid partial turn-around, agile and similar incremental solutions are the best. These embrace the “satisfy the customer” focus of the Agile manifesto and keep everyone in a high-efficiency mode. The key to this approach is that the team always has an objective that is reasonable. Thus, it is short-term ( a few weeks), and they are held accountable. The design and management of the project are much more active, though.

    The goal in this approach is to continually (every sprint of a few weeks) set up goals that are realistic. Likewise, they must advance the features for the users. The result is a highly flexible approach to solving the problem. The rapid turnaround earns the trust of users by regularly responding quickly. However, it can be overwhelming to the user base. They will work on a product that is regularly adding and improving features, which can be frustrating. On the other hand, this can be an approach that incrementally offers features to users. Thus, the solution is easily trained and learned through this piecemeal approach.

    The Best Approach

    Each of these approaches answers the challenge of getting to a solution quickly. That objective is valuable whether it is customer-facing or not. All of these embrace the Pareto principle that is far too often ignored in software development. Actually, it is ignored too often in many product development efforts. Worse, it is often ignored in problem-solving for businesses. We do not need the highest-end solution for all of our problems. Far too often, the budget solution is perfect for our needs. We can add bells, whistles, and deeper functionality inn the future. Thus, our best approach is a solution that works most of the time sooner rather than a complete solution weeks or months from now.

    Each of these approaches has a different goal. You can use MVP when you know you need to solve the problem sooner rather than later. A POC will answer whether your most significant problems or concerns can be met. Finally, the Agile approach will keep you churning out results regularly while building out a full-featured solution.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. We have experience in each of the approaches above and can help you make the most of them. Every project we work on includes demos and similar discussions regularly. Often every two weeks, including a release our customers can use to test the features further 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.