5.5. Defining the Project
Whether your IT project is needs-driven, assigned, or handed to you as a project plan, you should begin with defining the project. Remember, if the project is assigned as a project proposal or project plan, you'll need to review the proposal to validate the various project parameters included in the assignment. If there are any critical changes, they'll have to be submitted to the project sponsor for approval. If the project is solution-oriented or needs-driven, you'll need to create the project proposal to develop the project parameters and submit them for approval. In any case, you'll need to do your homework to make sure the project starts off on solid footing.
Let's begin with defining the initial steps for defining a project, regardless of its origins.
This doesn't have to be a long, drawn-out process. In many cases, you and a small team can go through the steps to define these five project elements in an hour or two. While the amount of time this takes varies with project size and complexity, it should not be a painful and arduous process. If you can't define the problem, mission, potential solutions, and selected solution within a reasonable amount of time, it should raise a flag for you that something is wrong.
5.5.1. Defining the Problem
We briefly mentioned the importance of defining the project problem. In this section, we'll look at the needs-driven project and the solution-oriented (assigned) project and why you should take time to define the problem. If your project came to you in the form of a project proposal or a full-blown project plan, you can review the solution-oriented or assigned project section. Then, we'll look at how to actually define the problem so you get your project off on the right foot.
18.104.22.168. Defining the Needs-Driven Project
Needs-driven projects are sometimes the easiest to work with only because they typically start with someone identifying a problem to be solved. The reason this is a bit easier to work with is because a good project definition begins with defining the problem to be solved. A project, by definition, is a unique solution to a problem. So, the ideal starting point is the problem statement. In a needs-driven project, this is often the process of clarifying the problem that's been identified. Using the example cited earlier, a needs-driven project might be upgrading all desktop systems to a newer, more stable operating system version. The original problem might have been raised this way, "Do you know the help desk staff has spent over 70 hours this month fixing system problems?" or an executive may have said "I'm really tired of my desktop hanging when I'm in the middle of working on a big project. I'd like you to find a better solution than constantly rebooting my system." In either case, a problem was identifiedthe desktop systems are unstable. Notice, however, that these problems are not necessarily stated in clear, defined ways. Someone on the IT team may come to you and mention that an executive was upset with system performance and wants a more permanent solution, or you may discover through routine report analysis that an excessive number of help desk hours are spent on a particular type of problem (in this case, system instability issues). You might decide that the problem is large enough to warrant upgrading the systems, so you decide to look into a project to accomplish this.
22.214.171.124. Defining the Solution-Oriented Project
Solution-oriented projects (including those that are handed to you as project proposals or project plans) are often assigned projects. Someone notices a problem and decides the best course of action and assigns a project to someone. These come about in two distinctly different ways. If you're the IT manager and you assign a project to someone on your team, you may very well assign the scope, time, cost, and quality metrics for the project. Based on your skills, experience and understanding of the assignment, there's a very good chance you can assign these four variables with a fair amount of accuracy. Still, the project manager for the assigned project should work through every step, including defining the project, to validate the project.
A second and very common scenario is when someone outside the IT department, typically an executive, assigns a project to the IT department or assigns a project to someone that includes a major IT component. In this case, it's entirely possible (or even likely) that the four assigned metrics are not based on experience or history, but are instead based on a business need. If this is the case, there is a strong chance that the four variables assigned will not be realistic or achievable. Now you're faced with a dilemma. You can move forward with the project knowing that at least one of the four metrics (scope, time, cost, quality) will not be achieved (unless you are incredibly lucky) or you can step back and define the project from the ground up. After defining the project problem as well as other steps, you may have to go back to the person who assigned the project and let him or her know what is realistic or achievable. While this might sound like bucking the chain of command, most reasonable executives want to know if there's a problem before it costs time and money. If you work in the type of organization where this type of dialog with those higher up in the organization is unacceptable, then you may have to simply have to continue along with all the project definition and planning steps, even if you are unable to change any of the project parameters. By going through every step, you'll at least know what you're up against and how close or far the assigned project is from reality. These steps should be followed regardless of whether or not you can change the parameters, and these steps may give you leverage to get the project modified or at least to record data for future use. However, in most organizations, you have the opportunity to clarify and provide additional information that may change the project parameters so that you and the project can be successful.
It is at this point in the project planning stage that you have your best shot at beginning to educate your higher-ups in the chain of command. While they may not want to hear the details of the project, you should make every reasonable attempt to help these executives understand the project planning process and why it's important that they listen to your feedback. Again, not all companies are going to allow this, but it doesn't mean you shouldn't give it a shot. Help the executive understand the process and most importantly, show what's in it for the company and the executive. Make the business case: "We can reduce the errors and rework in this project by following this defined process. The first step is validating the project proposal and these are the variances we've found." While you may not always be successful in these attempts, it is true that you "pay now or pay later." If a project must be completed in four months, it may well be completed in four months. It is also highly likely that the project will lack key functionality (scope) or may have errors (quality). It might also cost four times as much because it had to be done so quickly (cost). We'll talk more about the relationship of these elements in more detail later, but keep in mind that every chance you have to get your project sponsor and/or the executive team on board with the project management process should be fully utilized.
126.96.36.199. Defining the Problem Statement
Whether the project is needs-driven or assigned, you should begin with defining the problem to be solved by the project. When the project is needs-driven, it's often easier to see the problem to be solved and to develop a problem statement. With assigned projects, it might be more difficult to discern the problem and if possible, you might want be able to talk with the person who assigned the project and ask what problem he or she is trying to solve. The reason for doing this is simple. A project is a unique solution to a defined problem. If you define the wrong problem, you'll develop a solution that solves the wrong problem and might ultimately cause more problems than it solves. Starting at the very beginning is an important step for all projects so you can be clear about where you're headed.
Let's look at the example of system instability we used earlier. The problem was stated in two different ways. Someone saw that 70 hours of help desk time was spent during one month on dealing with system instability issues such as blue screen of death and other related issues. A second problem statement is the executive asking for a better solution to the computer problems since rebooting is inefficient and frustrating. Both describe the problem and can be used as the basis for defining the problem, though neither is an adequate problem statement.
The problem statement should be a clear, concise statement of the problem to be solved. Using this example, we can say the problem is "system instability is causing excessive help desk effort and user downtime. User downtime causes organizational inefficiency and user frustration." You might word it differently, but this is the essence of the problem. Another way to look at defining the problem is to ask the question, "Why should we care about this problem?"You might answer that question by stating that user downtime is inefficient and costs your company both in terms of inefficient use of help desk hours (that could be better spent doing something more productive) and loss of time and increased frustration for users. Defining the problem doesn't describe the solution. Notice that nowhere in our problem statements have we said that the solution should be to upgrade the desktop systems. So far, all we've done is say, "here's the problem" or "here's the reason we care about this problem." The result of this step is a project problem statement, shown in Figure 5.3 As you can probably tell, this step doesn't need to take hours. It might be a ten-minute exercise in some cases. Throughout the remainder of this book, you'll see these images. The shape on the left indicates a document. Within the shape is the name or title of the document. To the right of the shape are words describing the contents or nature of the document. So, the document that results from the preceding process is a problem statement. We'll continue to identify the type of document and the document contents at each step. Look for these icons throughout this and subsequent chapters to help identify tangible deliverables or outcomes from discrete steps. While each of these discrete deliverables should be captured in a document, they can all be captured in the same document, the project plan.
Figure 5-3. Project Problem Statement
It's possible you are thinking that since most of your projects are assigned and you're not expected to question the project assignment that you can skip this step. Don't. Even if you are powerless to modify the project parameters, you need to know how close (or far) this project is to reality. If you don't start with the project problem statement or definition, you'll never know if you're solving the right problem or not. Remember to take every opportunity to manage up the chain of command by educating higher-ups about the process and why it makes good business sense to do it in the manner described. You might not always win, but you'll never have someone say, "Why didn't you say something earlier?"
5.5.2. Defining the Project Mission Statement
After you've clearly defined the problem to be solved, you can then create the project mission statement. The project mission statement is really the desired outcome of the project. Remember, you're still not defining how you'll accomplish this projectthat comes in just a bit. For now, we're essentially performing a gap analysis. "Essentially, here's the problem and here's the desired outcome."
The project mission statement should be a short, concise statement about the outcomes to be achieved, not how those outcomes will be achieved. While this may sound a bit like verbal nitpicking, it's not. It's important that you define each element independently so that you don't make any very basic errors in your assumptions. A mistake in this definition process will be amplified so that later in the project, an error here will be very costly to reverse or repair. This is also used to state the exit criteria or how you will know when the project is successfully completed. Later, you'll define success criteria for the project, but a very concise statement here will also help avoid scope creep later on.
Using the example mentioned earlier, we'll use the problem statement regarding system instability and we'll develop a mission statement for it. The problem was stated in this way: "System instability is causing excessive help desk effort and user downtime. User downtime causes organizational inefficiency and user frustration." What would be the desired outcome then? We might state our project mission (or desired outcome) as, "To reduce user downtime and help desk staff hours related to desktop operating system faults and failures." Notice that we have not defined how we'll do this; we have not defined the solution. We have only defined the problem and the desired outcome. At this stage, you may not be able to define specific, measurable outcomes and that's ok. However, if you can, you'll be ahead of the curve later in your project planning. For instance, if you can state that you want to reduce down time by 85% from current levels, you have a much more specific statement about what you're trying to accomplish. If you can't yet define it this specifically, that's finelater activities will help you more clearly define specific measurable goals for your project.
A clearly defined mission statement is another very critical step in the project definition phase of project planning. It is possible that once you define the problem and the mission that you find your assigned project (whether it comes in the form of a suggested solution or a project proposal) is just flat out wrong. If you find that through defining the problem and mission that you come up with a different view of the project altogether, there's a disconnect somewhere that should be addressed. It's always easier to fix these gaps earlier than later, even if it means braving the potential irritation of higher-ups who may just want the project to get under way.
Notice that this process doesn't have to take forever. In many cases, once you've defined the problem clearly, the project mission statement almost writes itself because it's just the other side of the coin, so to speak. In some cases, you and your small, expert team can identify the problem and mission statement in just a few productive minutes together. Figure 5.4 shows the project mission statement as a defined result of this step.
Some people like to think of the project mission statement as the statement of work or the project charter. They're not exactly equivalent because the project mission statement simply defines the desired outcome(s). A statement of work or project charter certainly should contain (or summarize) the problem statement and the mission statement, but they are not interchangeable. We'll discuss statement of work and project charters in the next chapter.
Figure 5-4. Project Problem Statement
5.5.3. Identify Potential Solutions
If you haven't yet put together a small team to work with you on defining the project, you might want to do so now. They can validate the problem and mission statements (if you created them on your own or with your project sponsor) and they can help you identify all potential solutions. Schedule this meeting for an hour, bring food (always a good way to invite lively participation) and encourage folks to get creative. If you have fun with this and allow all potential solutions to be listed, you may find that someone has a brilliant idea that at first glance seemed outlandish or just plain crazy. It happens.
You'll want to begin by reviewing the project problem statement and mission statement. Then, ask the team to take ten minutes to write ideas down on a piece of paper. This allows everyone to think freely without outside influence or judgment. Once everyone has brainstormed on paper, have people share their ideas with the team. Write them all down and don't eliminate any just yeteven if they seem completely off-the-wall or unrealistic. If people think of other ideas while you're writing, encourage them to make a note of them and add them to the list since sometimes one person's idea sparks another new, unique idea for someone else.
Once you have a list of all potential solutions, make sure the list is complete. If you have a list of very sane, doable solutions, you haven't thought hard enough or big enough. You should have some crazy, over-the-top solutions on your list if everyone is being creative and participating fully. It doesn't matter that at first glance you might dismiss a handful of ideas for one reason or another. Sometimes it takes a crazy idea to spark a related thought. If you've heard the theory that there are only six people between any two people on this planet, such as you and the Dalai Lama (the six degrees of separation theory), it might also be true that there are only six crazy ideas between a bland one and a blockbuster. It's worth a shot, isn't it?
188.8.131.52. The Do Nothing Option
Add "do nothing" to your list of potential solutions. One trap many companies get caught in is knee-jerk responses to problems or crises either internally or in the marketplace. Sometimes you may find that doing nothing is actually the best solution. Rather than racing around creating a project, sometimes simply allowing a situation to resolve itself is the best option. This option should be considered, but it should be a conscious choice, not the result of vacillation or over-thinking a problem (that is, don't confuse "analysis paralysis" with an active "do nothing" choice).
184.108.40.206. Project Versus Process
Another trap that IT project managers and companies can fall into is that they define a whole new project when a process is what's needed. A project, by definition, is a unique solution to a problem. A process, on the other hand, is a defined set of repeatable steps taken to address an ongoing circumstance or problem. For instance, payroll is a process in most companies. You wouldn't create a new project every two weeks so people could get paid. Instead, you create a process to address how and when people get paid, how checks are delivered, and how problems with payroll are addressed. These are all processes because even though they may address problems, they are ongoing and are not unique (even if a unique problem pops up within the payroll process, it usually requires an adjustment to the process, not a project). You should make sure that the problem you're trying to solve requires a project and not a process.
Not to confuse matters, but sometimes a project is needed to develop a new process, and sometimes new processes are derived from projects. The key to keep in mind is that a process is used for ongoing activities and a project is a solution to a unique or one-time problem. While the lines can get blurry at times, make sure you stop and ask, "Would a process solve this problem better than a project?" If so, talk to the project sponsor and make your case for developing a new process rather than defining and implementing a new project.
Figure 5-5. Potential Project Solutions
5.5.4. Selecting the Optimal Solution
You and your small, expert team have developed the problem statement, the project mission statement and a list of potential solutions, even if you were handed the solution initially. Now, you will go through a process of looking at all potential solutions and rank them based on certain criteria (which we'll discuss in a moment). Even if you have been handed the solution you should still go through this exercise. If the solution bubbles up to the top, you've validated the solution. If the solution falls low in the list, you have invalidated the solution and perhaps found an even better solution to the stated problem. Of course, this can be tricky politically, but we'll deal with that later. For now, let's focus on finding the optimal solution.
220.127.116.11. Developing Ranking Criteria
You've got a long or short list of potential solutions that you and the team have developed. The next step is to develop the criteria against which you'll rate or rank these potential solutions. For instance, the project sponsor may have told you the project must be completed in less than six months or for less than $50,000. The project sponsor or the project proposal may have stated that certain requirements must be met such as the use of a particular technology, programming language or security algorithm. In some cases, these requirements are just thatrequirements that must be included in or addressed by the solution. In other cases, however, requirements are mentioned but they're really closer to suggested solutions. If you can discern the difference (or you know the difference based on how your organization works), so much the better. Don't work to meet requirements that are really suggested solutions if you and your team believe a better solution exists.
There is no standard set of criteria that we can give you to say, "Use this list to rank your potential solutions," because every situation is different. However, you can begin by looking once again at corporate and IT strategies and determining which of the potential solutions aligns best. You can also look at which potential solution(s) have the best business case or which approach seems most appropriate. You can also look at the market and determine if there are particular market requirements that must be met or potential market opportunities that can be exploited via your proposed solutions. These all help align the IT project to the business and market, which will make them easier to support and defend down the road if the going gets tough. These are all elements that can and should go into a project proposal if you're developing one, so this data will be put to good use.
Next, you should develop your target scope, time, cost, and quality metrics or definitions. Often these are assigned with a project. If they're not, you may need to discuss these elements with your project sponsor before you try to rank your potential solutions. For instance, if the project sponsor says that time is the most critical element and the project must be completed in less than four weeks, then any potential solution that you can intelligently estimate taking more than four weeks would be placed at the bottom of the priority list. Notice we placed them at the bottom of the list rather than tossing them aside. Things change and your sponsor might come back and say, "Well, maybe eight weeks at the most if you have a better idea."You'll be ready with a few alternatives.
Target scope, time, cost, and quality can be difficult to estimate, but often your project sponsor has a good idea on these targets. It's rare that a project is handed to you with absolutely no preconceived notion of duration and cost, though it does happen. If there are no set targets, then you can prioritize your potential solutions based on the approach that seems most logical, feasible, desirable, and affordable (see Chapter 2 for more on this). Logical, feasible, and desirable are all inexact labels based on judgment calls made by your and your team. However, in the absence of other, more exact criteria for your project, these may be good substitutes. Affordable is also a judgment call but it's usually a bit easier to determine for each potential solution. It's relatively easy to discern the difference in affordability between advertising in a few trade publications versus advertising during the Super Bowl.
18.104.22.168. Ranking Your List
Once you have developed your ranking criteria, you should rank each potential solution. You may find that a weighted ranking system works better than a simple ranking system. For instance, one or more criteria may be far more important than several other criteria. You may choose to assign a value of 5 for each important criteria and a value of 1 for other criteria. Each potential solution can then be ranked according to several criteria and the solution(s) that have the highest overall score should be those that meet the most critical criteria. Whatever ranking system you use, make sure it's clear, concise, and that everyone doing the ranking has the same understanding of the system.
22.214.171.124. Selecting Your Solution
If you have been able to create a ranked list of all potential solutions, the best solution(s) should be at or near the top of the list. Of course, there's nothing like a little human intelligence to optimize results, so if your ranked list doesn't seem to match the reality of the situation, you and your team should take steps to figure out why the ranking system didn't identify the optimal solution. If you and the team believe there is an optimal solution that is not at the top of the list, you can and should examine both your assumptions and your ranking criteria to make sure you're not just trying to promote the politically correct solution. It's possible that in some cases, you will still have to go with the politically correct solution, but you should at least know whether or not that solution is the best one.
Once you have identified Figure 5.6's optimal solution (and, unfortunately, we'll include the politically correct or required solution in here as well), you should identify the target scope, time, cost, and quality for that solution. Your next step is going to be to bring the problem, mission, and selected solution to your project sponsor for approval, so make sure you've got all the supporting data you'll need to back up your decision, especially if it differs from what was assigned. If that's the case, go back and review Chapters 2 and 3 to make sure you're ready to deal with the business and political realities in your company.
Figure 5-6. Optional Solution Identified