Tag: consulting

  • Configuration Vs. Coding – Modern Software Systems

    Configuration Vs. Coding – Modern Software Systems

    Over the years that I have been in the software development profession, I have watched solutions evolve dramatically.  The progress has gone from code to libraries to frameworks and now configurable systems.  However, there are trade-offs to consider when you look at a configurable system instead of one that allows for customization with code.  This is becoming a more common dilemma for businesses.  Thus, it is good to look at the pros and cons of each approach.  Here are some points to consider when measuring configuration vs. coding.

    The Power of Configuration

    Let’s start with the positives a configurable system brings to the table.  Configurable customization is where software of all sorts is heading.  Part of it is likely due to changing interfaces and keyboards becoming relics of the past.  However, there is far more value included.  I have found that the most significant value companies place in these systems is the lower cost of maintenance.  A configurable system constrains how changes are made.  Thus, it is easier to test those options thoroughly.  You also are less likely to have typo related issues.  The inputs can be highly constrained and validated.  For example, a drop-down selection item is not susceptible to a typo.

    There is also a lower technical threshold for configurable systems.  Administrators can often learn all they need to know with a few days of training.  As opposed to years required to build stable and scalable code.  This approach has the side effect of reducing the number of points of failure in many cases.  Less information has to be communicated across departments.  Thus, for example, a marketing employee can make changes to the system.  The alternative is to relate them to a developer to code.  Business users can focus on their business rather than how to communicate to the technical staff.

    Coding is Here to Stay

    With all that configurable systems have to offer, there is still a level of control given up.  The limits that make these systems so powerful also keep them from doing precisely what is needed.  A customer is also at the mercy of the vendor for these systems.  A required feature may be a long time coming, and critical functions may disappear.  These may be worst-case scenarios, but that is enough for many to choose a custom coded solution.

    Every business is different, and coding allows for software to be built to precise specifications.  Your priorities can be crafted into the software.  Then, it can change as your business needs change.  There is also ownership of the product to consider.  A custom solution is owned by the creator and not a vendor.  You can change it as needed and do not need to worry about the future stability of the vendor.  Better yet, any problems that occur are your own.  There is one place to look for solutions.   Thus, no time wasted on support calls to get a response to meet your schedule.

    Configuration vs. Coding – The Bottom Line

    I could list dozens more pros and cons for each side.  However, the decision is pretty simple.  A configurable system is the better solution in most cases.  One has to recognize that the 80-20 rule holds for these systems.  Therefore, configuration is an excellent choice.  The configurable piece of the solutions often allows a company to get 90-95+ percent of its needs met adequately while avoiding the costs and headaches of custom software.  It also allows you to buy the experience of the teams that created the software.  They used their expertise to solve common problems.  This may not get you to one hundred percent coverage, but it will provide tested solutions for eighty-plus.

    Finally, do not underestimate the value of fixed cost solutions.  Your vendor is providing you a solution that is complete.  There are no concerns of improper estimates, scope creep, or schedule overruns.  Therefore, the focus is on using the solution, not creating one.

  • The Importance of Communicating Status and Plans

    The Importance of Communicating Status and Plans

    One of the best ways to control project success is to meet or exceed expectations.  One of the best ways to understand and impact expectations is through regular status and review.  Therefore, status reporting habits are an excellent way to improve the chances of success for your project.

    A Failure of Communicating Status

    I had an experience that has made me a firm believer in providing my clients with a weekly status.  In this case, the problem came from a sub that I trusted, and a customer that was happy and trusting.  I would periodically touch base on progress and tasks.  I left things to run on their own as did the client.

    We had some communication issues that led to my sub doing more testing and rework than the customer desired.  This confusion would have been a small problem if caught early, but instead, it went on for weeks.  Thus, by the time the client saw a large number of hours on small numbers of tasks, it looked like they were getting over-billed.  In a sense, they were.  Therefore, we ended up eating a bunch of billed hours and rolled the sub off of the client.

    A weekly status of hours and work would have brought this issue to a head earlier.  That early catch would have been easy to correct and saved headaches on both sides.  This situation could have ended worse, but part of the reason I did not over-communicate was due to the great relationship I had with the client.

    A Lesson Learned

    I learned from this bad experience that communicating status is an important detail to address.  I now send a status each week to every client large and small.  Most status reports are one project and one page.  However, sometimes I go to multiple projects per client and multiple pages.  I may also append some pages of notes or deliverable recap to make it easy to link tasks to outcomes.The status I send is not very complicated.  I list what was done, roughly how many hours were spent on the tasks, and then estimates of tasks and time for the week ahead.

    The status report takes less than fifteen minutes to put together each week.  However, I did spend close to an hour creating a template that is easy to fill out and still looks pretty good. Thus, the time I invested has more than paid for itself over the last few years.

    The status I send is not very complicated.  I list what was done, roughly how many hours were spent on the tasks, and then estimates of tasks and time for the week ahead.  This takes maybe fifteen minutes to put together each week.  However, I did spend close to an hour creating a template that is easy to fill out and still looks pretty good. Thus, the time I invested has more than paid for itself over the last few years.

    Keep It Simple

    The art of making a weekly status valuable is in its brevity.  Keep to simple line items and maybe even a summary at the top.  Consider that a client will only read the first part of the status.  Anything below the fold may be missed.  In particular, this scanning of status will occur as they receive one week after week.  Yes, it is a little bit of a CYA, but the real goal of this is to make sure you are on the same page as your clients about work to be done and priorities.

    A weekly status call would be a good way to keep it simple, but I recommend a written version as well.  The report provides something for future reference by your client.  However, it also provides you a great checklist to make sure your tasks completed each week match what you said you would do.  Communicating status seems like something everyone knows and values, but it is easy to get away from the process.  Beware if you do.  The lack of communication can cost contracts, clients, or even reputation.

  • Contractors or Employees? Options for Growing Your Team

    Contractors or Employees? Options for Growing Your Team

    In building a team one of the first questions that need to be answered is whether you will use contractors or employees.  Although this decision may be dictated by circumstances, it is important to recognize the pros and cons of each.  In the spirit of full disclosure, I have been a contractor for most of the last decade.

    Let’s look at the positives of employees first

    Loyalty used to be a huge plus for employees, but that seems to be less a factor every year.  However, an employee does still improve the likelihood of team continuity.  Employees may leave your organization, but it is more likely that contractors will move on.  This can cause a drain of business-specific knowledge.  Consequently, employees are more likely to give a return on the investment of training them on your processes.

    An employee also provides more ability for you to impact their attitude.  Never discount the productivity that can come from a happy and motivated employee.  There are steps you can take to make contractors happy.  However, you will have much more at your disposal to keep and motivate an employee.

    Contractors will sometimes talk about a partnership with their customers.  This is a good attitude to have, but at the end of the day, an employee is more closely bound to a company.  Their future is tied to the company success in a more direct manner than any contractor.  This symbiotic relationship does not guarantee everyone works together.  There are always going to be politics and personalities that drive a team.  Nevertheless, employees are at least going to have some shared benefits to come from a successful company.

    Finally, contractors tend to be project focused.  Your company may hire contractors for the long-term, but most will come in, focus on a project, and then move on.  This works for turnkey projects.  However, it is not the most efficient way to build a living, growing solution.  There are always ideas during implementation that get set aside but are valuable in future releases.

    Contractors have a different set of positive attributes

    It may seem cold, but contractors are disposable.  The investment made in a contractor should always be smaller than an employee.  Training and benefits are worries of the vendor, not your company.  A contractor should be primarily a short-term resource and it is usually easy to end a contract.  In any case, you let contractors go, but have to fire employees.  This has a lower cost no matter how you slice it.

    A contractor brings a new set of skills and experience.  Employees will have shared experience over time.  That is a strength of building a team but can also lead to a form of tunnel vision.  A contractor will have a different set of experiences and often can bring a new set of skills to the team.  They also will be on the hook to keep their skills current and marketable.  This can be a way to improve the overall skills of the team without paying for more training.

    One of the biggest strengths of using contractors in my experience is the ability to flex up and down those resources.  It is almost always easier to find another contractor than it is to hire someone.  You can also reduce contractor headcount quickly and reduce costs during slow seasons of business.  In fact, this is my most recommended approach to software development.  I recommend and have followed the process of building a core team that is small.  Once the team is in place, use contractors to handle peak or high-need times.  This keeps overall costs and commitments low while still getting work done.