Tag: design

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

  • How Soon Do You Need It? – Quick Solutions

    How Soon Do You Need It? – Quick Solutions

    Monetary cost is a crucial ingredient to any project plan. However, time is also essential. Quick solutions almost always cost more and have lower quality due to constraints on building them. The three-legged stool is time-money-resources, and that last one pulls less weight. There is often a limit to the impact resources can make. You can not get nine women to make a baby in one month. While this holds for all three of those constraints, time may be the most valuable to have in abundance.

    Quick Solutions vs. Better Ones

    Sometimes, a project or product can be done quickly and still be of high quality. Unfortunately, that is rarely the case. Instead, we must put in the hours and work to think through the problem and adequately craft an answer. Thus, the more time you have to work on the product or application, the more freedom you have to adjust for finances, resources, and quality. That makes it tempting to get a product built and shipped or installed, but its usefulness will be questionable. You would not want a doctor to rush through surgery. Likewise, rushed software is terrible software. That is one of the reasons projects so often fail.

    Setting Your Time Limits

    Timing is a difficult question to answer. Of course, we always want something sooner rather than later. However, there are hard limits to your schedule that come from various factors.

    • A commercial product launch window
    • Financial or Calendar year
    • Business and compliance deadlines
    • Seasonal or cyclical needs
    • Synchronize with business plans
    • Return on investment
    • Quality

    These are essential constraints that can help you answer the timing question and might push you towards or away from quick solutions.

    A Launch Window

    Even the best solutions have a lifespan and window of opportunity. We must meet those market deadlines for our product to be viable. Sometimes, that is a wide window, and sometimes, a tight fit. You might be forced to adjust features to squeeze it in this constraint. For example, you might know you can be first to market if you ship by a specific date and need that advantage. You can research the IDE tools released in the early ’90s when Java hit the scene to see how those things can play out. There were a few lower quality tools that aimed for first to market.

    Annual and Cyclical Targets

    Launch windows can be tough to determine. Others are hard deadlines and easy to factor in. A good example is when you are releasing a solution or features that will impact accounting. Whether it is monthly reports or payroll, there are times when mistakes during product release can be devastating. This is why many companies have quiet periods around the busy sales months.

    Synchronizing the Release

    There are other tasks related to product releases that are not technical. These include sales and marketing materials, training, packaging, and more. These related tasks can add time constraints that we need to include. On the other hand, these same tasks can sometimes give us more time than we expected. For example, when we miss a cyclical target, we can add weeks or more to our release window to achieve our objectives before the next cycle.

    ROI and Quality

    We all have seen products just shoved out the door to make a quick return. While that is a viable business model, it is rarely sustainable. If you have quick solutions of low quality, then you need to make your ROI quickly before everyone sees you have an inferior product. A high-quality product can increase your ROI and shift your focus towards a better product later rather than lower quality sooner. These business decisions are essential to decide when you start your project.

    Signing Off On This Question

    This question can be answered in a few ways. There is the desired time frame or deadlines, and then there are alternatives. You may not have an alternative. There are cases where you must have a product available by a specific date or timeframe to make it viable. Other times allow for multiple time windows, and you should have plans that consider those. That might also point to a phased release with an MVP for the first deadline and enhancements to follow. In any case, know what you are working with before you begin.

    Improve Software Success

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

  • What Is Your Budget? Setting Constraints For Your Solution

    What Is Your Budget? Setting Constraints For Your Solution

    This question is one of the primary ones to answer for any project or endeavor. Your budget is a crucial constraint and a guide to building the perfect solution for you. Of course, we all want a good deal and are happy to have our needs met for a lower cost than we expect. However, we also go into a project with an idea of what the solution is worth. That means we would be better off spending our budget on a complete solution than less money on a sub-par solution.

    Your Budget Provides a Target

    Think about any large project. For our purposes, we can use building a house. The budget is a critical part of the limitations to design. The architect cannot properly design your home without having the budget in mind. You might only be able to afford a small one-bedroom with one bath, or maybe, you want dozens of those and high-end interior design. Whether they undershoot or overshoot your budget by a lot, you are likely to be disappointed at the very least.

    Match Vision To Reality

    The challenge in matching your budget and vision is knowing what various features will cost. For example, you might want an extra bathroom for your house but need to know the cost of that over another closet. Software is the same in that fashion. Your project will be more likely to match your vision when you clearly understand the features available and their respective costs. That includes time as well as money. The maintenance costs may also be a factor in your decision, so a long-term budget is helpful.

    Factors To Consider

    Yes, we brought up the “M” word. There are costs for your solution that go beyond the initial costs. Those can include items we easily miss.

    • Recurring license fees
    • Hosting and Backups
    • Updates and Security
    • User Support and Administration
    • Data and Integration Updates
    • Bug Fixes Beyond the Initial Contract

    If any of these are confusing to you, make sure they are part of the discussions with your provider. You can also reach out to us for more details on what these recurring costs can look like. On the other hand, we have many similar areas where we need to be aware of options that can dramatically impact a solution. Those are a longer and more granular list.

    • Support for multiple users
    • Security considerations (external attacks)
    • Compliance requirements (HIPPA, Sarbanes-Oxley, GDPR, etc.)
    • Administration screens and tools
    • Training and Documentation
    • Online Help
    • Internal Security and Permissions
    • Data backups and Disaster Recovery
    • Platforms supported (web application, mobile support, desktop application, etc.)
    • Multi-lingual support
    • Remote Access
    • Functionality While Disconnected (i.e., no Internet)
    • The list goes on…

    Many factors can impact the cost and, thus, your budget. While you do not need to understand all of the above cost factors, you need to know how flexible your budget and vision are. There will be trade-offs. Thus, the more you have a general idea about the available features, the more you can adjust your vision. Of course, if you have an unlimited budget, it simplifies some of these questions.

    Making the Trade-Offs

    The other questions we have to answer for our project to be successful will help us adjust or conform to our budget. Decisions require us to eliminate paths or options. Therefore, we must be sure of our objectives to avoid choosing an approach that makes a goal impossible. There is also a cost associated with refactoring and change requests that we can avoid when we do a better job of scoping things out from the start. Finally, when our budget is tight, we need to aim for a more straightforward or less complete solution to avoid spending too much on one feature at the cost of another. The simple solution may be the only one we can afford. All of this again points to finding a partner who understands software development, your business, and your vision and can give you the details needed to make informed decisions.

    Signing Off On This Question

    You can think of this question as a box you are filling up. The objective is to decide on the size of the box. Then, you get to start filling it with features and determine if you want breathing space or are ok with a box about to burst. The important part about this is to realize that what you can fit in the box will vary, and you want to know the size and shape of the box when you start. When you decide to go with a different box somewhere down the road, you will need to unpack the one and then repack it to fit the new package. Do not be afraid to share your budget with your vendors or partners, as it gives them a lot of insight into what is possible for you.

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