Blog

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

  • Managing Upgrades and Software Versions

    Managing Upgrades and Software Versions

    Managing upgrades is something we all face. That. is true whether you are running your software in your house, at a small business, or for an enterprise. There are versions released regularly as often as quarterly, and sometimes we get the new version “free,” sometimes not. There are many things to consider when crafting a version roadmap for your software. Here are some things to help with that. These suggestions and warnings come from a broad experience with software and highlight some paths that can make your life easier.

    Managing Upgrades Through Major Versions

    The “old school” approach to managing upgrades was often made via major versions. Software companies would release a major version every year or so. Then you would take the time to get up to date. That approach quickly morphed into a leapfrog approach for many companies. The disruption of performing upgrades and costs of installs were enough that the benefits were often not worth the effort. There were also licensing constraints that made an “every other version” approach much more effective in time and cost.

    That approach is an excellent model for planning a version roadmap. There is always a cost to embracing/installing a new version. Often it works better for us to take on more changes less frequently rather than smaller changes more frequently. This approach also gives plenty of time for changes to “bake in” to the organization. Thus, allowing processes to evolve to embrace new features.

    Managing Upgrades Through Features

    Software used to promise needed features with every release. However, we have moved to a world where features are driven more by internal needs than marketing bullet points. Many organizations are content with staying on a version for years. These organizations prefer stability, and an upgrade tends to be large and feature-rich. That sometimes includes a push to move off of a version that is no longer supported.

    The risk with the above approach is running out of time before a release is unsupported. Likewise, the resources and upgrade paths can be limited. Less frequent upgrades can lead to much more complex paths and can put data at risk. Some applications go through “watershed” upgrades that require a significant data migration effort. Those typically require the users to be on a specific version before the migration is done rather than skipping through multiple versions.

    Obstacles and Road Signs

    The approaches listed are both valid, and either may be a perfect fit for your organization. We have already touched on some things to look out for. However, it is good to have a list to walk through in planning out your approach.

    • Be aware of watershed releases – When you have a release that will effectively be incompatible with prior versions, that can often be a “need to upgrade” marker.
    • Store Version media or packages – There are combinations of software required for a version that can become difficult to replace. Vendors move forward or may even cease to exist. Thus, it can be critical to access prior versions of software and even operating system tools when you delay your upgrades.
    • Know Your Features – I have found that it is rarely a good idea to take an upgrade just because it is available. While there is risk involved, there is also the factor of utilization. It is important to know what your software can do, and blindly upgrading can miss out on valuable features. Invest the time for reviewing release notes and training updates when available. This investment can pay for itself quickly and inform you of whether future upgrades are valuable or not for your needs.

    The Cloud Factor

    Software as a service and the Cloud can make these types of issues seem a thing of the past. However, even SAAS products have versions and upgrades. You might be in a situation where you can hold off on a version upgrade for a while, but that is rare. Even in those cases where you have a “choice,” it often is presented as a preview you can embrace sooner rather than later. While you lack choice, there are still actions you can take (and should) as part of your upgrade strategy.

    • Take advantage of backup options where possible.
    • Use and verify export options where possible. It is your data, make sure you have access to it outside of the SAAS product.
    • Keep current on planned upgrades, enhancements, and outages.
    • Plan for some time to test and verify updates.
    • Embrace the latest features as suitable to your needs.
    • Avoid company critical periods of work that coincide with a maintenance period or upgrade.

    The good and bad part of a SAAS product is that you are not responsible for the workings of that product. A lot of the management and administration tasks are taken out of your hands. Nevertheless, the steps above can help you mitigate risk at the cost of taking some of that management back on yourself. It is worth that trade-off. You will be happy to have a way to take your data elsewhere when a product becomes unusable, or a provider closes shop.

  • When To Fire A Client

    When To Fire A Client

    Recent events have me thinking about the pros and cons of when to fire a client. It is often a difficult decision to make and even more complicated than accepting a contract or customer. The challenge in accepting a customer includes questions such as whether you can take on the additional work or the profitability of the work. Once you land a customer, you are used to that revenue and level of work. Yes, even if that work includes headaches.

    Unprofitable? Fire A Client

    While there are challenges to it, a client that is not profitable is the easiest to get rid of. There is a bottom line to consider and a black or white decision. The larger obstacle is deciding to get rid of a profitable client but a pain. We all know a customer like this. They do the ‘right” thing and pay bills on time. However, they constantly disrupt plans, cause us to stress, or give us steady fodder for complaints. First, let’s assume we are not merely whining. That is not only possible but is something I see more often than I want to admit. Yes, even when I am the none doing the whining. Next, we need to evaluate the cost of the stress or other negative impact.

    Is This self-inflicted?

    Once we have decided this is not about profit or paying bills, we need to assess the source of the stress honestly. In IT, there are many reasons for us to experience stress in a project. These include timeframes, deadlines, technology platforms, version hell, and normal interpersonal challenges. In my experience, the technology challenges are worth working through. You will see these with other customers. Better yet, a solution that reduces obstacles inherent to a technology platform is re-usable and can win future clients. The steps required for these solutions can be painful. However, the reward can be substantial and worth the temporary stress.

    While it takes two to tango, I have found that we can often place the majority of interpersonal challenges among customers and vendors on one side or the other. Let’s start with the case where we are the problem. This situation can arise when a project is outside of our skillset, goes beyond our resources, or is generally not to our liking. The quick solution in these cases might be termed as “suck it up, buttercup.” However, that may not be the best approach. While we all have some level of ‘grunt work” or other unpleasantness to handle as part of our job, that is not always required. When we have a customer taking us in a direction that does not suit us, it is worthwhile to send them to another vendor. Happy workers are more productive. Why waste our good workers on things that drain them without due cause. Profit is not enough. Make sure the overall benefit is there for any given project.

    They Are A Toxic Client

    The heading for this section is a bit harsh. A bad client is not necessarily toxic. Nevertheless, most bad clients have some toxicity in their company that makes them a challenge. The flaw may be in their communication, culture, or just an individual. We will leave the last option for last. When this problem is the client, it is worthwhile to assess how much pain and suffering they cause. Likewise, we need to assess any positives that may come from a successful project. Sometimes success in a bad situation can be a game-changer for our company’s success. On the other hand, a doomed project can sink an enterprise. We need to make sure we can overcome the challenges and be legitimately successful if we move forward.

    Do Not Be A Quitter

    I have known people to give up on marriages and long-term friendships over minor things, but not customers. It almost goes unsaid that we should not fire a client too hastily. In my experience, a customer is held on to longer than they should instead of the other extreme. That being said, a difficult project or situation is not enough to turn them away once we have started. The focus should be on whether or not the customer relationship can be successful. Likewise, there is some point where it has to be profitable to both parties. When you take a loss with a customer for no sound reason, then it is simply charity. Nevertheless, we should not walk away abruptly. Even a bad relationship deserves closure. Please find a way to transition them to self-sufficiency or another vendor that has a (preferably better) chance of success. You will not regret it.

    The Value Of Loyalty

    Before we wrap up these thoughts, I feel loyalty is worth a mention. Some situations go sour or bad over time, and those that experience bumpy roads or obstacles. A vendor that takes on those periods of challenge and sticks with their customers even in the bad times will often find rewards at the end. These rewards may not come from that difficult customer, but they do come. There are lessons learned and “brownie points” that we earn when we are known to be a vendor that cares about our customers. Think of major brands, and you will often find that sentiment buried somewhere in the branding. People buy from those they know, like, and trust. Trust is earned in the trenches, not through the easy times.

    A Way Forward

    All of these thoughts boil down to some steps you can take to assess whether to fire a client.

    • Is it us or them?
    • Can a solution be found that benefits both parties?
    • What are the benefits of staying as opposed to firing them?
    • How do we extract ourselves from the relationship with a minimum of damage and ill will?

    These may seem simple. However, each of the above bullet points can be very nuanced and complex.