Blog

  • Software On A Budget – Building Your Solution Without Breaking The Bank

    Software On A Budget – Building Your Solution Without Breaking The Bank

    One of the worst kept secrets in the world is that software is expensive to create. Thus, software on a budget seems to be an impossible goal. There are low-cost solutions here and there. However, most software solutions require a lot of hours of work from experienced (expensive) resources. Even a solution that looks like it might be a good deal is often far from what you expected once it is complete. We see this in budget over-runs and a general lack of satisfaction with projects of all kinds. While I can not reverse those facts, there are ways to get what you pay for. You might even have money left over to throw a party.

    Know Your Problem

    Software solutions are built based on solving a problem. Herein lies the struggle for everyone involved in the process. The cost and scope of the solution are going to be directly tied to the problem. Therefore, solving different problems have different associated challenges and costs. For example, adding two plus three is not the same as adding any two numbers. Likewise, a web site with a single page that describes your business is not the same as a site that provides a product catalog and payment processing.

    These challenges are made more complicated when the target changes. We often set goals that change as we progress towards them. This is not a vagary of software alone. Think about buying a car. You may start with a desire to have a high-end stereo system, bucket seats, and a sunroof. However, you learn that it is a far better deal to skip the sunroof and that was not something high on your priority list. We need to be sure of what problem is being solved and what is required to do so.

    The Minimum Viable Product

    That brings us to the idea of an MVP. This is a product that covers what we need for a solution and no more. Think about a meal. All you need food and drink. That is the MVP. Of course, there is a lot of difference in steak and wine compared to bread and water. Both of these options solve the problem. However, they may not solve variations of the problem. For example, you might need a meal for under a dollar or can not eat meat or consume carbs, or any other constraints. When we want to confine a solution to a budget, we need to define the problem. There is a trade-off of time spent defining the problem. Thus, less time is spent during implementation.

    This process is no different than any other instructions. The more details you provide, the more likely the solution is to match the problem. That is where a lot of budgets are blown. There is a lack of detail provided about the problem and it leaves too much room for variance in the solution. Even worse, each variance that needs to be adjusted to get the solution back on-track adds cost.

    Build On The Work Of Others

    There are those that want to avoid creating a “derivative” product. This thought can lead to avoiding the use of tools and libraries that can save a lot of time and money. Unfortunately, a lot can be gained by building on the work of others. There is a substantial amount of detail you can address by looking at a competing product. It is not as simple as saying “I want a site like Ebay.” However, that can be a starting point. Substantial savings can come from screenshots of similar sites and marking up the image with notes and edits. Do not forget that a picture is worth a thousand words.

    Function Over Form

    The best route to adequately solving your problem is to focus on the results. The look and feel of the solution are a minor part of the result. Once you get the right answer, then you can “pretty it up.” Many projects get this out of order, and hours are burned in changing fonts, colors, or button placement instead of validating the solution itself. This approach can be referred to as the “why” of our project. That should be your guiding light as you march through your project. If you accomplish this goal, then you will be able to build software on a budget. It may seem like an impossible challenge to keep your project on track. However, all you really have to do is to keep the main thing the main thing.

    Simple Questions To Achieve Software On A Budget

    All of this boils down to a few questions you should ask every step of the project. When you keep these in mind it will help you keep things on track.

    1. How does this help us solve our core problem?
    2. Does this highlight a gap in our definition of the problem or desired solution?
    3. Is there a simpler way to achieve this goal?
    4. Has this particular problem already been solved?

    These may seem simple or even obvious. Nevertheless, they are the keys to creating software on a budget. These questions help you focus on reigning in drift where it occurs. If you still have questions, feel free to schedule some time to discuss your project and how to get it done the best way possible without burning through your budget.

  • Agile Patterns For Success – Team Work

    Agile Patterns For Success – Team Work

    I recently spent some time digging deep into the world of the Agile Manifesto and related methods for software development. This research included a look at agile patterns and anti-patterns. That is my focus in this article. There was an underlying theme that I kept coming across and do not see emphasized often enough. Spoiler alert, that theme is teamwork. There are many aspects of Agile that make it an effective way to approach software. However, the true power and ability to succeed comes from how it empowers the team.

    The Team Defined

    First, we need to be clear about how the team is defined in Agile. This is often the development team but can also include the scrum master and product owner. For our purposes in the article, we will focus on the development team. Many of these patterns make the entire team better. Nevertheless, I want to focus on the development team as they are the workhorses for our software project. These are the people that most impact success or failure when we build a solution.

    Unleash The Team

    It should be common sense that the biggest factor in any calculation is the one that becomes the largest focus. In sports, you hear about a player that “has to be stopped.” In politics and advertising, you hear about ket demographics. Businesses have flagship products and cornerstone customers. The odd thing is that we miss this concept when we consider teams. There may be an individual that is the most productive or effective on a team. However, the team is key, not just the individual. We have seen this played out in numerous contexts and multiple times over the years. Yes, a leader can make a sizable difference. On the other hand, most leaders are measured by how they motivate their team and increase productivity.

    The best leaders remove obstacles for their team. They reduce “red tape,” streamline processes, and empower team members. There is another way to view this. The best leaders unleash their team members to be the best team they can be. That takes us back to a focus on the team, not the leader. In case this example seems a bit abstract, managers are leaders.

    Professionals Are Professional

    The essential cog in the whole Agile Manifesto is that a development team is built of professionals. The members were hired because someone saw them as bringing value to the organization. Why would we throw that out once we place them on a team? It would seem to be common sense to trust these professionals to know how to do their job best. They know what their experience and skills are as well as where they work best.

    That leaves managers to listen to their staff and find ways to clear obstacles. It may seem trivial or lack glamour. On the other hand, it makes a statement that team members are valued as individuals. They are trusted to make the team the best it can be. Sure, there can be conflicts and a need for team members to learn how to work together. However, how often are we able to make other people like or trust each other? Managers are not miracle workers. Do not force employees into a hole. Let them define their role.

    Agile Patterns Are Not Suited For Everyone

    The second most important idea that needs to be understood in this pattern is that some teams are not suited to Agile. We need to have a team that has some experience, has self-awareness, and is driven to succeed. The team can develop these criteria as they go, but they need a starting point. A team full of similar or junior members will struggle. If there is not enough time for the members to branch out and differentiate themselves, Agile will not work. This concept goes back to that trust factor.

    When the team is trusted to “get the job done,” let them do the work. When you question whether the team can succeed, then do not burden them with Agile. They have to be able to make decisions and have confidence in those. Members that have no experience will rarely be able to do this. Instead, they will suffer from stress and lack of direction. Agile will be the worst direction to take.

    Agile patterns start and begin with the team. When you have a team that has the ability to over-achieve then turn them loose. Your trust and vote of confidence will be rewarded.

  • Making Fixed Bid Projects A Success

    Making Fixed Bid Projects A Success

    I am not a fan of fixed bid projects in general. That distaste is such that I have turned some down in the past. However, sometimes we need to step into one of these arrangements. It is worth considering the actions we need to take to keep such projects fair to all parties. Here are some lessons I have learned from personal experience and from others that have entered into these agreements. The successes and failures are excellent teachers for this billing strategy.

    Fixed Bid Struggles

    I want to start the discussion by highlighting some of the weaknesses of this process that we want to overcome. The first is that it pits parties against each other. It is in the best interest of the customer to get as much into the project as they can while the provider will want the least in it. Ideally, there will be a “just right” amount of work in the project, so the work that is done matches the compensation. This goal highlights another weakness. The vendor will want to “pad” the price to cover overages while the customer will focus on the lowest cost. Thus, any time the work is not highly defined, the two sides are hedging their risk for the work-compensation ratio. Finally, changes are difficult for these projects. Every little change will potentially require the vendor to be paid more, and the customer will want to argue against that. This situation often triggers conversations about what is a “bug” and features that were implied or assumed.

    Reduce The Competition

    The first and foremost issue we want to remove is pitting the parties against each other. The best way to resolve this is to get the pieces defined and set in place from the start. We want to set expectations for everyone involved. Our challenge lies in reducing (or at least identifying) the risks involved in a project. Thus, it is best to “chop up” the project into smaller pieces that can be easily defined and assessed. That leads to milestones. I think these are the key to successful fixed bid projects. Likewise, the are others that agree with me.

    Milestones are an excellent way to reduce a complex project into smaller, more manageable pieces. Likewise, each milestone has reduced overall risk and allows the parties to make adjustments as the project proceeds. Each step along the way will have a set of deliverables, a time frame, and a related cost. This process can still work within a greater fixed bid budget for time and cost. However, it will highlight issues sooner in the process so the parties can open discussions before one or both are in an untenable situation.

    The Sum Of The Parts

    The “just right” amount of work balanced against the requirements can be challenging to assess with a large project. When the work is simplified into a series of milestones, it becomes easier to find that balance. The focus for both functions and meeting them becomes smaller and more likely to comprehend. For example, think about your favorite application that has multiple top-level menus. Most Word Processing and Spreadsheet applications fall into this category. If you were to assess how that application meets a set of requirements, it is far easier to do so a menu item at a time than trying to look for features across all items. This thought process is not rocket science; we need to consider that adding items adds complexity and expands focus. This challenge is no different than discussing a single decision as opposed to a series of them. There are flow and side effects that come into play far more often in an extensive system than those milestones. These can make it harder for all parties to do their respective jobs.

    Managing Changes

    Change requests are always a challenge as the project progresses. There are bugs, requirements changes, and scope changes that can fall into this category. Typically, bugs are part of the fixed amount while the other two may require a fixed addition. I have found it helps to start with a bid and expectations that includes some minor changes. When you take this approach you get to avoid “nickel and dime” issues where large amounts of time are spent haggling through each item. When this happens, a project can slow to a crawl. There is always the option of pushing changes off until a project completes. However, there are times when that is not realistic. Of course, adding in some “buffer” for changes can make it hard to do an apple to apple comparison of project bids.

    Changes are more of a challenge when they are done in a granular matter. The better your ability (on both sides) to group these tasks into a bundle, the less the headache. When you avoid minute details of tasks, you avoid long conversations with little benefit. This also allows for “buffer” required per job to be rolled into a total buffer amount that will often be far less than the sum of the individual items. There is a form of averaging of risk that can be applied. Think of it as being able to make fewer estimations and risk assessments. It is not much different than an insurance company assessing risk across a large number of customers rather than having to spend time on each individual.

    The Bottom Line

    When you think about an hourly rate or time and materials, it is similar to milestones of an hour (or the time block paid). However, there are not always going to be a deliverable for those milestones other than time spent. Ideally, we have two goals. The first is to complete the overall project. The second is to complete the steps required to reach the primary objective. We can use milestones to bundle together hours of work into a deliverable and reduce risk on both sides. Each party just needs to stay open to the idea of adjustments along the way.