Tag: solutions

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

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

  • Sticking To The Plan – Completing A Project

    Sticking To The Plan – Completing A Project

    One of the most frustrating situations in software development is when one side decides to “change the rules.” There have been examples on both sides of the equation that I have seen ultimately derail a project right before completing a project. We even do it to ourselves at times. I hope that listing a few common mistakes will help you identify and avoid them in the future. It may bring world peace a step closer.

    The Nickel And Dime

    There is nothing I can think of that destroys trust between customers and vendors than either side chipping away at the other. A vendor does this with a steady stream of little change request charges. Instead of working together with clear deliverables and a plan, they get stuck in the weeds. A client does this by trying to get tasks turned into “non-billable” and drags the team into unnecessary detail. The thing about software development is that it is complicated in most situations. There is enough to worry about without nitpicking the details late in the game. Do not read this as the “details” being unimportant. They are critical in completing a project successfully. It is just that those need to be hashed out early on and not when the end is nigh. When you do this, you will avoid a feeling of death by a thousand cuts.

    Just A Little More

    This particular anti-pattern may be the one I relate to most. There are two conflicting traits many of us see as we approach the end of a project. However, they can combine to spin us off into oblivion. The first trait is what I call the “90% high”. This situation occurs when we “know” we are almost through with a project and have a burst of energy to get across that finish line. Think of it as a runner sprinting that last one hundred yards of a marathon.

    The other trait is one we will call “just a little more.” This situation arises when we feel we are close to the end and can squeeze in a few more features or finishing touches. When we have that extra energy to drive to the end and a desire to keep adding a little scope, we can rapidly go off course. It is almost like we do not want to get across that finish line and instead want to stay “in the zone” as long as possible.

    Perfection Over Reality

    Sometimes completing a project is hindered by quality assurance and testing results. The application is almost complete except there are some bugs to fix. While some bugs must be addressed to provide a useful product, some others do not. For example, I have seen projects wallow in testing cycles as minor things like pixel-perfect displays, wording for labels, and fonts or sizes are “fixed.” These might be issues that impact the usability and correctness of a product. However, that is rarely the case.

    These sort of nit-picking details can drag out the testing cycle beyond reason. Keep an option for “known bugs” that can be addressed in a future version. Users may not wait forever while you perfect that current release. Even worse, I have seen situations where wording (copy) is minutely engineered only to find out that it ends up negatively impacting users. Yes, even copy can be over-engineered.

    Agile To Infinity

    One of the strengths of an Agile approach is that releases should be common and regular. However, that does not stop some groups from dragging out a production release. This situation is similar to the “just a lttle more” pattern. However, in this case, production releases are pushed off for “just one more sprint” instead of tightening things up and pushing it to users. Instead of a litttle item here or there, this pattern becomes a few more features, bug fixes, or performance improvements. Sometimes there has to be a person the team that can make the “fish or cut bait” call and drag the project across the finish line.

    These are just a few of the ways to avoid completing a project. You can find anti-patterns all over the web. Nevertheless, I find these to be highly common and often easy to avoid. Of course, it all starts with a plan, and then the team needs to keep working towards that plan. Changing mid-course can turn you right into an anti-pattern.