Tag: projects

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

  • Scary Statistics About IT Projects

    Scary Statistics About IT Projects

    InfoGraphic-Scary IT Project Statistics

    It is no secret that IT projects are less than a roaring success most of the time.  However, when you start to look at the numbers around success rates and reasons for overruns it gets scary.  The problems we face are not new.  There have been IT projects documented for over a half century.  There is nothing scary about IT projects on their own; we just need to face the everyday struggles and address them to improve success rates.

    Patience and Communication is not Scary

    The problems around most IT projects can be boiled down to lack of patience and communication.  Fortunately, these are problems faced throughout a business.  Therefore, they are not only solvable, they are addressed every day in other areas.

    InfoGraphic-Scary IT Project Statistics

    Every important initiative and project have a vision of success and a payoff.  Thus, it is only natural that we want to get the improvements started.  Furthermore, we want them implemented as soon as possible.  In IT projects, this can lead to short design periods and a rush through requirements gathering.  The implementation starts too early because we think we can “fill in the gaps” of the requirements while the solution is built.  This situation is often referred to as building the track when the train has already left the station.  Our rush to get going can leave us open to all sort of problems later on.

    Proper Communication

    Communication is like productivity.  You can “do” a lot and not be productive.  This situation is also known as “busywork.”  Our day is full of communication that is similar to busywork.  The result is not very useful even when large amounts of text or data are communicated.  In the project world, this is what happens when we swap a bunch of emails and attend a bunch of meetings, but fail to document the details of decisions.  Worse than that, sometimes the details are documented, but the documentation is not shared with the whole team.  We adopt a “need to know” basis for sharing the requirements and design details.

    We will look deeper into running a successful project in the weeks to come.  Until then, check out the attached infographic for some scary statistics and pitfalls to avoid whether you are just getting started or deeply into the implementation of a solution.

  • Writing Good Requirements

    Writing Good Requirements

    There is a discernable difference between novice and veteran requirement writers.  The process is more art than science, but it still has some best practices that can be of help to anyone.  Here are some points to consider that can help you make your next requirements document the best one you have written.

    Outline the Requirements

    In my experience, this is the most natural step.  Start with a high-level overview of needs for the project.  This helps set the stage for greater detail while providing a core design.  It is important to have this basic design as it provides a reference point as the details are refined that can help avoid drift.  Once this outline is created it can, and should, be regularly referenced during the definition of detailed requirements to ensure the details link back to core features.

    The highest level outline of requirements is the vision for the project.  The outline is the general view of what is to be created and drift from the vision is highly discouraged.  It does not mean the vision cannot be altered or refined.  However, a project is a plan for moving from A to B.  The B is the vision.  Therefore, changing B as the focus can create situations where you “take the scenic route” or even become hopelessly lost.

     

    Ask “Now What?”

    Once the outline comes together, it is time to go to the next level.  This point is where most requirements fall apart.  There are a set of questions that a well-defined requirement will answer.  Let’s look at each one and what to consider in answering it.

    How do I get to this point?

    This question looks at how a requirement is executed.  It includes considering who can access a feature and whether it has limits for different users or times.  For example, an ATM has a requirement to dispense money.  To receive cash, someone must be authenticated to the system (card and PIN).  An authenticated user has made a request for withdrawal.  The account has been selected, and it has a balance greater than the sum to dispense.  Keep this example in mind as we look at the other questions.

    What data should I have once I get to this requirement?

    This question addresses the state or environment we can expect while fulfilling a need.  It potentially includes defining how the data is gathered in the first place.  Thus, we might find some more requirements to be determined while answering this question.  In the above ATM example, we should have an account number, an authenticated flag and an amount to withdraw.  Thus, we should have requirements defined that address how an account number is gathered, how to mark a user as authenticated, and how to tell the system what to withdraw.

    What is the expectation when this requirement is fulfilled?

    At this point, we define what success means for the requirement.  If we can not determine success or failure of a requirement, then it is either not needed or ill-defined.  For example, an ATM withdrawal results in cash dispensed and an account debited.  There may be new expectations as well, but they should all be defined as part of answering this question.

    Where do I go from this requirement?

    The first question we asked is the entry to this requirement.  This question is the exit.  Once a requirement is fulfilled, we need to examine the options for proceeding.  Often the answer to this issue is a list of “locations” based on success or failure.  In the ATM example, we will show a success message, an error screen, or might go back to the main menu.  This step is where we might turn up some other entry requirements to define.  For example, is there a “quick cash” option that skips going back to the main menu and instead logs the user out after dispensing cash?  Alternately, is there an optional “print receipt” step to consider?

    What happens if an error occurs?

    This is the question most often missed in my experience.  Our vision is all about the success of the system, but errors occur, and those must be defined as well.  In the ATM example, a user might not have a high enough balance to their account.  The ATM might not have enough cash on hand, or the dispenser automation might be broken.  The list of potential errors can get lengthy, but they need to be examined.  This long list can be simplified into an “exception bucket” that covers errors we can’t think of, but the more we tightly define the errors and corrections the more reliable the result will be.

    Do I need to communicate success or failure of this requirement?

    I see this question skipped more often than I expect.  Once a requirement can be considered a success or failure, does a notification need to occur?  This may be a report, a log entry, or any other communication method.  We might even want to provide multiple responses.  In the ATM example, the notification is likely a printed receipt (report), a beep or sound to note the process is complete, and a message on the screen.  Success is the most likely result to be communicated; it is the error communication that we often forget to define.  Do we ping a maintenance service if the cash on hand is insufficient?  Do we notify authorities if the authentication is a blatant fraud attempt?  These sort of error messages should be defined and are as important (maybe more so) as the communication of success.

     

    Defining requirements is an art form of sorts, but following some simple guidelines can make anyone more effective.  If your requirements have not considered and answered these questions then doing so can improve the likelihood of a successful project.