Author: Rob Broadhead

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

     

     

  • Project Kickoff – Simple Steps to Success

    Project Kickoff – Simple Steps to Success

    IT projects do not have a great success rate.  However, a project kickoff that includes some simple steps can significantly improve its odds.  These are not technical steps so anyone can do them.  If your next project skips these steps, then it is more likely to become another unpleasant statistic.

    The Big Why

    The first step in a project kickoff is: clearly define your why.  We have looked at this in past posts, and it is critical on your journey.  The “why” of your project helps you define where you are going and parameters for the trip.  Do not stop with just defining it either.  The team should have the “why” communicated to them, and that should provide a focus for them during design, implementation, and beyond.  The better the “why” is defined and understood by the team, the less likely there will be functional or other drift.

    What Are We Solving?

    This step is similar to the “why.”  Accordingly, it is the next logical step.  First, we define our project at a high level.  Next, we list the problem or problems we are solving.  The problem solved is the answer to an important question, “Why should anyone care?”  We do not take on projects just to spin our wheels.  There is always a problem that is being solved, and that is what gives the project value.

    What Are Our Assumptions?

    This question is a tough one.  Unfortunately, this is where a lot of the pitfalls also live.  When a project is envisioned, there are often pieces that we take for granted.  For example, let’s consider building an application that makes it easy to move money among banks accounts.  We are likely assuming that there is a login, user authentication, bank account linking features, error messages, fraud restrictions, and much more.  All of these functions are critical to the success of the project, but easily overlooked when we ask a team to implement it.

    What Can Go Wrong?

    This is a step where two things are assessed and listed.  There are the risks to the project success.  The risks include lack of resources, lack of funding, competition beating us to market, etc.  Then there are the exceptions to the solution.  These include handling bad data, loss of needed connectivity, and even things like a forgotten password.  At this point, none of these items need to be addressed at a detailed level; they just need to be considered.  The goal of this step is to ensure we are aware of potential risks and pitfalls and the plan take them into account.  We also might find priorities that come from this action.  For example, the market window for a product may be known to close in a known time frame.  The product has to be completed in that period to have any chance of success.

    Beyond the Project Kickoff

    It is important to note that this is just the project kickoff.  However, defining answers to these questions at the start of a project will give them the needed weight during design and implementation.  When you look at reasons for IT project failure, responding to these questions and communicating them to the project team is an excellent way to improve the chance of a successful project.