Tag: solutions

  • Back To Basics – Getting A Project Back On Track

    Back To Basics – Getting A Project Back On Track

    When you listen to a professional or college sports team discuss a bad stretch, they often mention that they will get back to basics.  These statements are not a knock on the players.  They understand the basics.  It is instead a focus on doing the things that have to be done.  It is a return to their foundation so they can simplify and then work on building again.  This approach happens to work well for software projects as well.

    Spinning Out Of Control

    The good and bad news is that software projects almost never go just a little off-track.  A slight stumble in a project either gets righted quickly or it starts to spiral away.  Thus, it tends to be easy to see that a plan is out of control when you look at it on paper.  There will be features that are not implemented, slipped dates, and requirements that have been ignored.

    Like the coach of a team struggling to succeed, we can simplify without getting bogged down in blame or questioning the skills of the team.  This approach is not just saving the feelings of the team members; it also happens to be an excellent way to triage the situation.

    Back To Basics = Simplify

    I think the best benefit that comes from this approach is that it forces us to simplify and focus.  The first step is to look at the requirements and assess where the software is about them.  When I say requirements, I am talking about the original, not the ones with a pile of change requests.  Those change requests may be vitally important, but let’s ignore them for now.

    Once you have the gap analysis complete on the software and the starting requirements, it is time to tackle the scope creep and change requests.  As you move through these items, start each one by asking if it is required.  Nice-to-have features often show up in early change requests because we have a lower bar of entry.  When things are on schedule and expectations are met, we are happy to add a feature or two.  That changes once we are behind schedule or on a death march.

    The Baby and The Bathwater

    There will almost always be changes that can be made to the scope at this point.  Things have gone for a reason.  There are cases where a technical issue or challenge causes a project to go off the rails.  However, I have rarely experienced this.  It is far more prevalent to have a project die due to a thousand cuts.  There are all sorts of little slips and additions that have led us to this wreck.

    That being said, our gap analysis will almost always highlight opportunities for removing features and simplifying the project.  When we tackle these, it needs to be with discretion.  Some features can be turned off to reduce scope without much effort.  However, many will have tentacles reaching into other areas.  Thus, unlike a sports team, we may have features that we need to keep due to the complexity.  Of course, if we have good adherence to version control best practices, we should not run into this problem.  If you just fell on the floor laughing, you are not alone.

    It is important to note that this is a perfect example of where good version control practices can help.  You can use branches and tags to group and categorize the features as you remove them.  This will allow you to attempt merging those features back in for a future release.

     

    The Bottom Line

    When you find yourself in the middle a project catastrophe, get back to basics.  Focus on the requirements you have to meet and a simplified target.  You do not get to cut out some of the basics.  Thus, testing, code reviews, comments/documentation, and those other areas of the SDLC we like to skimp on are not valid targets for getting on track.  You may do these in a less flowery way and simplify some of those processes, but throwing them out is only going to get you back to this position in the future.

    Are you struggling with a project today?  Take a shot at going back to basics and see if that doesn’t quickly give you a path to success.  This is not a silver bullet.  There is still work to be done and corrections to be made.  However, this can get you headed to the light at the end of a tunnel instead of the next oncoming train.

  • Gathering and Defining Requirements

    Gathering and Defining Requirements

    One of the first steps in any projects is gathering and defining requirements.  These are needed to measure whether the features being built are useful.  Requirements also give us a way to map progress and eventual success.  Sometimes there are projects where we will have all the information we need to get started.  However, most projects will require us to gather, define, and refine these details from others.

    Gathering Requirements

    The process of gathering requirements from others can be complicated and time consuming.  Luckily, this is not always the case.  Gathering requirements can be straightforward when you follow the step below.  The order is not as important as performing each of these along the way.

    Find The Focus

    This is the primary reason for the project in the first place.  It is often a problem or group of problems to solve.  There should be a business reason for solving the problem.  Make sure this reason is understood.  Some requirements will be set directly from this focus, but it has a greater value.  That value is to lay a foundation for the requirements.  When a requirement is assessed, the focus of the project determines whether to include or exclude.

    For example, assume the focus of a project is to provide a quick way to enter a shopping list on a mobile device.  A requirement to force the user to enter a login and password each time would be excluded.  That function goes against the focus.  Not every requirement will be that easy to assess.  However, knowing and sticking to the focus can avoid scope creep.

    Define The Foundation

    In this step, the goal is to define some of the base features of the solution.  Over time these sort of features become standard questions for a stake-holder.  These will vary depending on the project.  However, this list is a good start.

    • What are the security considerations? Multiple Users?
    • Will reporting be required?
    • Is auditing or logging going to be required?
    • Does this require an offline/online mode?
    • Is mobile support needed?
    • How will this be used? (Web, Desktop, Mobile, etc.)
    • Do users need to be able to interact with each other? Be grouped?
    • What features will be used often and which used rarely?
    • Will data need to be kept forever? Briefly?
    These questions should be a start to adding your own.  Sometimes you will have the answers immediately.  However, when you can not answer them, pose them to the stake-holders.

    Create a Plan

    Once the requirements are gathered it is time to create a plan.  USe the requirements to build a story of how the solution will be used and how it will work.  This process is important for verifying with stake-holders, but also helps find gaps.  When requirements are viewed as a whole then often gaps will appear.  Think of a story with loose ends.  When requirements are not complete there will be loose ends that need to be addressed.  Thus, more requirements need to be defined.

    Verify Your Assumptions

    Take the plan to the stake-holders.  The plan should provide a complete story that makes sense to them.  This not only provides validation for the requirements that have been gathered, it also ties them together.  This step is often one that sparks stake-holder discussions about process steps and outliers that were missed.  However, It is often not a reflection on the requirements gathering.  Instead, it is a way to prompt for outliers and rare occurrences.

     

  • The Cost of Technology

    The Cost of Technology

    It is hard to run a business without paying attention to IT at some level.  The required amount of work might be as simple as keeping up with a couple of subscriptions to websites.  On the other hand, it can be as complex as running a team of thousands.  Although IT provides several options, the cost of technology in solutions is often estimated incorrectly.

    In these cases (and all points between) one of the most important factors to keep in mind is cost.  The cost in both time and treasure.  The world of IT provides many options.  There are going to be solutions that are too cheap and will never support your business. Alternately, there will be solutions that are too complex and expensive.  Either of these can sink your business through lost time or finances.

    If you are an IT professional with decades of experience in building and assessing solutions this cost analysis might come quickly to you.  However, for those non-IT people in the world, let’s look at some areas of research to determine if a solution is right for you.

    (more…)