Blog

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

     

  • Native Mobile vs. Mobile-Friendly

    Native Mobile vs. Mobile-Friendly

    Mobile devices are becoming more popular every day.  Thus, it is more important to have a mobile strategy.  If you are delivering a service or product via the Internet, then you need to decide whether to go the native approach deliver a mobile-friendly solution.

    What’s The Difference?

    The first thing to clarify is the difference between a native and mobile-friendly approach.  A native mobile application is installed on the device.  It runs on the mobile device and potentially has access to everything on the device.  This access includes storage, cameras, and sound.  Since the application is on the device, it can run without an Internet connection.

    A mobile friendly solution is a website that works fine with mobile devices.  The application is run in a browser and requires an Internet connection, but otherwise, can look and feel like any other application on the device.

    Why Native?

    Native applications can be advertised and marketed through vendor stores.  This is the Apple App Store and Google Play for some devices.  Thus, getting your solution on the right stores can quickly expose it to millions of potential users.

    A native solution does not need to be connected, so it potentially has a greater use.  Unless a user is in a situation where they always have robust and reliable Internet access, there will be times the application lags or is unavailable.  Native solves that problem and can even sync back up to the Internet when needed.  Think about a painter that goes to provide estimates.  They want to be able to enter data for a job even when there is no connectivity available.

    Native applications also have deeper access to the device.  Thus, they are much more capable of utilizing the screen, camera, and other features.  This includes other applications.  Thus, a native app can take a picture and email it from your email app to someone on your contact list.

    Why Mobile-Friendly?

    To be honest, most of the mobile-friendly arguments center around cost and resources.  A mobile-friendly solution is built for the web and mobile standards.  This means that when Apple or Samsung release a new device the app will still work on them.  There is no need to spend time coding a solution for every device (or family of devices) out there.

    Although the application stores are an excellent way to market a solution, they can be time-consuming to use.  There are also restrictions on application certification for updates after the application is released.  This can put more pressure on developers and testing to be as feature complete as possible for each release.  Thus, it takes longer to get your solution in front of your customers.

    Native applications typically cost more to develop.  There are tools to help target multiple devices with a single codebase, but there are still implementation and testing considerations that make native development more expensive.  This also includes creating the app in a way that it will get accepted into a store.

    A single method of delivery (the web) makes it easier to provide a consistent experience for all users.  Whenever a user goes to the site, they will have all the functionality and not have to worry whether the mobile solution has the same features as the web.

    Which One Should I Choose?

    In general, there is no clear winner with either of these options.  The best path to take requires several considerations.

    • Do my customers need the application even without the Internet?
    • Do my clients have mobile devices or typically use a browser?
    • Can I need to support one (or a small number) device or will many brands need to be addressed?
    • Is time to market a critical factor?
    • Is this an application that app stores will automatically reject?
    • What resources and budget do I have available?
    • Is native a goal I can work towards rather than hit it in version 1.0?
    • What are the key features/functions of the solution?
    • Are the essential functions possible with a web solution?

    These are just a few of the questions and decisions that go into a mobile strategy.  The import of mobile has grown to the point that it is a sound investment to consult with professionals.  The best experts to ask may already be in your company IT department, or there are a lot of good providers available within a wide range of budgets.

    Delivering a mobile solution is big business.  It is also a big decision.  Therefore, it is worth your time and resources to plan out a strategy.  The old days of “lets build a mobile app” as a strategy are long gone.  Set your mobile strategy and move into the future with confidence.

  • Creating a Project Team – The Things to Consider

    Creating a Project Team – The Things to Consider

    Whether you have resources on hand or are building from scratch, a good project team requires planning.  We always want to create a team that is more than a collection of the members.  Luckily, the history of good and bad teams gives us some keys to success.

    Communication

    As we see with project failure reasons, communication is important.  A good team will not only communicate among themselves, but there also should be someone that can share with others.  This role may fall to the leader or manager, but a team that does not have someone to be “the voice” of the team will struggle.  This person may be a good writer, speaker, or presenter; the point is communication.  A team that cannot interact within and without is doomed to failure.  Lack of communication is a common source of project issues.

    Complementary Skills

    We often hear about groups and organizations with “too many chiefs” that struggle to be effective.  In fact, this concept applies to nearly any role.  The members of a project team should complement each other in their skills rather than all be the same.  For example, we have mentioned communication, and there are also design, planning, implementation, and testing areas of skills that should be possessed by the team.  A team full of communicators is not very useful if they do not have a mix of the other skills.  In particular, find a leader/motivator and then there is no need for another one.  Some skills are useful in multiple team members (e.g. testing, implementation).  However, many skills should only exist with one member (or a small percentage) to avoid conflicts.  Even two superb leaders can butt heads over an issue and thus negate each other’s skills.

    A Project Team of Old and New

    Everyone loves a good process and set of best practices.  The problem is that those tried and true approaches do not always work.  It takes a new pair of eyes to see where innovation and improvement can be made.  Thus, find a mix of project team members that are veterans and those that are newer to the focus of the project.  The veterans can help jump start the team with their experience and knowledge of how to approach the solution.  The neophytes can learn from the veterans while asking questions in case there is a better way to get the job done.

    Define Roles Clearly

    When a team is built, there are often roles that members are assigned.  These roles should be clearly noted and not assumed.  In particular, do this for the positions where you only want a member, or two focused on that aspect.  Assuming that everyone knows who should do what on a team often leads to confusion.  It can cause minor problems like slowing the team down or even be the source of crippling internal conflicts.  Remember that everyone on a team should have a role or roles, and they should be clear on what theirs are.