Author: Rob Broadhead

  • Making the Most of The Implementation Phase

    Making the Most of The Implementation Phase

    The amount of time spent on each step of the software development life cycle varies from project to project.  However, the implementation phase is always the most significant portion.  That means this is the area where projects can fail or succeed.  We can ace all of the other steps in the life cycle, and a mediocre implementation will wipe out all that good work.

    Balance The Effort

    In my experience, the most impact during implementation is to try for a balanced effort from start to finish.  Avoid a slow start and then hectic finish to hit deadlines.  Particularly for longer stretches of implementation and big projects.  This is a killer of productivity and quality.  I have seen project after project that burns out team members with a hard push at the end that could have been avoided.  The way to accomplish this is to set proper milestones and goals that balance the effort throughout the phase.  When you keep the goals in sight, it is easier to keep everyone focused and avoid the lazy drift big projects see at the start.

    Regular Sanity Checks

    Another essential trait of a successful implementation phase is regular checkups.  These are not progress focused as much as they are about requirements.  There are a variety of ways to do this, but the result should be a review of what is being implemented to ensure it is still in line with the requirements.  This includes reducing feature creep as well as correcting design drift.  Short projects will not suffer from this too much.  However, long-term or large projects can see dramatic implementation problems and slipped dates from adding features or skewed solutions to requirements.

    The good news is that this task does not need to be done by the implementation team.  Team members from other phases (or QA staff) can perform sanity checks of features.  They can measure against requirements and then meet with the implementation team to correct problems.

    Frequent Code Commits

    This may seem minor, but regular code commits are critical.  I have come across numerous projects that tank because of impossible code merge needs, or a team member disappears along with their source.  Ideally, this is built into the daily regimen of the implementation team.  Regular merge and build steps are a big help as well.  Much like the sanity checks above, regularly testing that you have all you need for a successful build helps keep from drift.  This factor is a solid argument for best practices like continuous integration and regular builds.

    Test Early

    Testing has gotten better but still is too often left to the end of the project.  This is when the cost to correct errors is at the highest level.  It has been established over the years that the earlier a bug is detected, the easier it is to fix.  There is a bit of a challenge in early testing as (by definition) the implementation is not yet complete and ready for full testing.  This timing also means that there will be more time spent testing than when it is held until the end.  That is entirely ok.  The more testing that can get done, the more likely bugs will be found and squashed.

    When you combine early testing with regular builds and commits you get feedback early, and quality is built in from the start.  This approach even makes the testing process better.  The test scripts and tools can be used and refined during the implementation phase to improve coverage and confidence in the results.

    Note that none of these improvements are substantial on their own.  These can be implemented as part of the process and pay worthwhile dividends when the project completes.  All of these can also be tried out to see how they work for you.  When in doubt, give it a shot and verify for yourself whether these are good for your team.

  • A mentoring presentation on creating an effective RFP process and documents. (AKA RFP tutorial)

    A mentoring presentation on creating an effective RFP process and documents. (AKA RFP tutorial)

    I decided to go over lessons learned from my experience with several RFP projects over the last few years.  I learned a lot from an excellent mentor and have added my own touches to create a process and documents that have been highly effective in a broad range of situations.  This provides a form of RFP tutorial that is highly recommended for anyone going through one for the first time.

    You can find it here: https://youtu.be/dx8vlSoUXs0

  • Scaling Effectiveness – From Individual To Team

    Scaling Effectiveness – From Individual To Team

    Whether you are an employee, entrepreneur, contractor, or other, there comes the point where you need to scale your abilities.  We can only do so much on our own.  Thus, the need for extending effectiveness arises as soon as we try to do anything of substance.  The trick is in finding ways to train others to produce a quality that is close enough to ours.

    A Specialist Problem

    It goes without saying that this problem is one faced by specialists and those in skilled positions.  If your work is measured by time put in and the quality of your work is not a factor, then you scale by adding more resources.  Thus, we can build assembly lines of low-skilled labor and scale that to create millions of products.

    In the world of business and IT, there are very few low-skill positions (if any).  There are a few positions that are low-skilled that amount to data entry, but even those often require knowledge and experience to get the job done faster or better.  Therefore, to grow our business, we need to be able to develop our people.  We need to find ways to peel off some of the skilled labor we do, convert it to something that takes less skill, and pass it on to someone else.

    An Age Old Challenge

    Good News.  There is nothing new about needing to pass on skills to others or even the next generation.  However, we do seem to forget about that as something that requires our attention.  Our days are full, and we quickly fall into the trap of being “too busy” to think about how to delegate.  We need only look back a few decades to see industries driven by apprentice programs.  These were the first way we looked into scaling our skilled labor.

    Dissect How You Work

    The first step in delegating those things that only you can do is to examine your tasks closely.  There is often some form of “finishing touch” we put on our work while most of the functions could be done by anyone.  Even a software developer can have someone else write their code.  This procedure is quite a challenge as it amounts to putting your thoughts down in a document.  Nevertheless, it can be done, and the process is an excellent insight into delegating almost any responsibility.

    I recently wrote a tutorial on how to automate almost anything.  The beautiful thing is that this process is practically the reverse.  You have a method you follow as part of delivering a product or service.  We can dissect it by reducing it to the steps we take.  There will be steps that are hard to define like “think about the problem I am solving.”  That is ok for now.  We will parse that more another time.

    Once we have the first pass of steps, there are going to be concrete actions, and probably some “magic happens here” areas where we struggle to define our process.  Those specific actions are where we move next.

    Actions Reduce Skill Requirements

    Those concrete actions are where we can most quickly scale out our process.  The operations may require some level of skill.  However, a well-defined task can be done with more ability through practice.  We may be able to perform the work faster or at a higher quality than someone else.  Fear not, that is a temporary setback.  When we pull out that step and hand it off to someone else to do the work, we will also spend the time to review and assess their work.  This is an investment in making the worker better at the task.  At some point, we will be able to have our investment pay off in a job we can reliably hand off to another.

    Once we have a task or two pulled out to hand off, we can work on adding more to that list.  This allows us to scale as others do those tasks better (through training or experience) and as we take things off of our plate.

    Scaling Effectiveness Is That Simple

    So, we define the actions we take, find some we can hand off, and then do so.  We scale by repeating the process.  Is it that simple?  Yes, the procedure is not hard at all.  It is the definition of the tasks that is often a challenge.  Do not take my word for it.  Where are you invaluable to your job?  Spend some time to find at least one task you can hand to others and see how easy it is.