Tag: projects

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

     

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

     

  • Project Success – Solving The Right Problems

    Project Success – Solving The Right Problems

    When we talk about starting a project off correctly, we often mention problems to be solved. Unfortunately, solving problems alone is not the path to success.  We must also make sure we are solving the right problems.  Luckily, this task is not challenging and just requires us to ask a few questions.

    Who Do We Ask?

    The first thing to do is to identify who speaks for the solution.  This speaker is the person or persons that will use the product.  They may be subject matter experts (SME), but more often are an end-user or a representative for the users.  These people are easy to identify because they are the ones faced with the problems we are solving.  These are the people on the front line that will be most impacted by the solution.

    For example, an accounting package may be required to have features based on the desires of the CFO.  However, the accountants using the software need to be able to enter and retrieve the data the CFO wishes.  Since the users are ultimately providing the features to the CFO, then they are the ones that will best define the problem.

    What Do We Ask?

    Once the target speakers are identified, it helps to explore their routines.  Make sure you go beyond daily routines as there are processes that only run weekly, monthly, or annually.  As they share their schedule, there are opportunities to point out pain points and struggles they have.  Ask them what they find most annoying or time-consuming in their routine.  Look for repetitive tasks that can be automated or simplified.

    Ask them how beneficial the solution is to them when the interview process is done.  List out what problems are going to be solved.  This list should get a response along the lines of “that will significantly improve my life.”  Be clear about the solutions as far as what it will, and will not, provide.  This is a critical part of setting expectations.

    Digging Deeper to Find What We Are Solving

    An important part of the interview process is digging down to the core problem.  There are problems that only exist because of the current processes.  Once you ask why something is done you might find a simpler solution.

    A favorite example I ran into (and similar to several other situations) dealt with a large report.  The solution was a web application that dealt with data on millions of objects.  The user needed a report that could bring back millions of rows almost instantly.  They were fine with a paging solution, but did not want to accept a solution where we asked for search criteria that brought back less data.

    As we dug into the goals we found out that no one actually needed all those records returned.  No shock there.  No human can consume millions of records.  They wanted the records so they could see the count of records returned.  Yes, the end solution was to provide a record count based on any search.  A single number is what was needed, not complex queries and paging solutions.

    Never Stop Learning

    The moral to this story is to understand the problems to be solved.  Do not simply have them listed and then run off to craft a solution.  Understand the “how” and “why” of the problems.  This will help you design a solution that is useful to the end user and not a complex approach that is too slow, expensive, or hard to understand.  Better yet, look for milestones where the speakers for the project can assess how the solution is going and provide feedback.  It never hurts to check your work along the way.