Section 6.7. Defining Project Processes

6.7. Defining Project Processes

We're heading down the home stretch here. Defining the project's processes and procedures is the final step in this phase of our planning. To this point, you've identified a tremendous amount of information about the project, and now it's time to define the project's processes and procedureshow the project will run and how you'll run the project.

Cheat Sheet…
Processes, Procedures, and Stress

You already know that process for process's sake is a waste of time, but when processes (and procedures) make sense, they're priceless. A renowned exercise physiologist, Michael Hewitt, has researched and written a lot about exercise (bear with us, we'll get to the point quickly). His philosophy is to find the least amount of exercise needed to remain healthy. That's an attitude you've got to love and that's our approach to process. Look for the least amount of process and procedure possible to generate a calm, consistent, and manageable project team environment. Predefined processes and procedures reduce stress because people know in advance how to handle routine situations. However, those same people can feel stressed out when there are so many processes and procedures that they literally can't get their jobs done. Find the least amount of process you can to make your project manageable and be careful not to build in so much process that everyone spends time on process and none on the project itself. Help your team be productive by defining key project processes and procedures. If possible, work with the project team to define these so that the processes will be ones the whole team can live and die by.

There are many different processes and procedures your project may need and it's impossible to define and discuss every possibility. We'll discuss many of the more common ones and discuss their components so you can develop your IT project's processes and procedures using these as a starting point. If you find yourself in the midst of your project (once it's underway) and there are areas that seem confusing or are causing errors, delays, or frustration, they may be candidates for additional processes or procedures. If you find yourself or your IT team solving the same problem over and over, it's a likely candidate for a new process or procedure. The flip side is don't define more processes or procedures than are necessarykeep your project processes lean and mean to keep your IT team moving forward on project work. The following is a partial list of processes and procedures you might want to define for your project. We'll discuss each one briefly and there are several that we'll discuss in more detail in subsequent chapters.

• Acceptance Criteria

• Risk Management Plan

• Change Management Plan

• Communication Plan

• Quality Management Plan

• Status Reporting

• Defect/Error/Issue Tracking

• Escalation Procedures

• Documentation Procedures

• Approval Procedures

• Deployment Plan

• Operations Plan

• Training Plan

You may already have some or all of these procedures and processes defined from previous projects. If so, double-check that they're applicable to your project and feel free to reuse any that make sense. Some may need to be tweaked a bit and others can be used as-is. Others may not address the current project needs and will have to be tossed aside or rewritten. Any time you can reuse work from a previous project, do so. If you (or someone you trust) took time to think through a process in the past, you may as well leverage that work, but do so only after reviewing it to ensure it's still applicable.

6.7.1. Acceptance Criteria

We discussed acceptance criteria earlier, so we won't cover that again. Keep in mind that acceptance criteria really define the process by which the user or client formally accepts the project's deliverables. It's critical to define these with the user or customer and to gain agreement on the acceptance criteria before the project gets underway (or as soon as acceptance criteria can be accurately developed) or you risk some confusion (or outright finger-pointing) later on.

6.7.2. Risk Management Plan

We'll discuss risk management in a later chapter, so for now, we'll simply mention that risk management is a process you should have in place for your project, regardless of how big or small the project is. Every project faces risks and spending time identifying those risks before you begin the actual project work will help you avoid the "running around with your hair on fire" syndrome that often hits IT project managers at some point during the project. Good risk management planning gives you intelligent, viable alternatives when identified risks occur. Great risk management can help you avoid the problem in the first place by knowing that it might happen and taking steps to avoid it altogether.

6.7.3. Change Management Plan

We all know that despite our best efforts to plan, things change. One of the most common changes to a project plan is that the users (those who will utilize the deliverables of the project) come back and say, "Oh, we forgot, we have to have this, that, and the other thing."This happens whether you have a hardware or software project, an internal or external project, a small or a complex project. You know changes to your project will happen, so you can choose to manage that process or not. If you choose not to manage the process, you can end up with a project that looks like spaghettia jumbled mess. Since there usually are many dependencies in a project, changing one thing typically changes one or more other things in your project plan, creating a ripple effect. We'll discuss creating a change management plan, or process, so you can manage how, when, and why your project changes.

6.7.4. Communication Plan

You'll hear a lot about communications plans throughout this book because they are some of the most overlooked processes in IT project management. Many IT departments are not very good at communicating with anyone except others within the IT department. You may bristle at that statement, but the overwhelming number of complaints registered about IT departments is that requests go in and silence comes out. If this does not describe you or your IT department, you are to be congratulated. The rest of you know who you are…and in later chapters we'll talk about creating effective (and simple) communications plans so you can break the pattern and the perception of poor communication from IT. It's possible you never thought of communicating as a process, so you've already learned something that can help you communicate more effectively by establishing processes and procedures to make your life easier.

6.7.5. Quality Management Plan

In Chapter 7, we're going to discuss quality. It's been given its very own chapter because quality is a critical part of all projects and managing quality touches all aspects of the project. So, while quality is built into a project from the ground up and is defined and managed at each step, we will devote a chapter to identifying this in more detail. As a process or procedure, you may also have a separate Quality Management or Quality Assurance Plan. If you're using any one of a number of quality programs (Six Sigma, ISO9000, etc.), you may have a framework for managing quality that is separate from the IT project management process. If so, it integrates well with the IT PM processes and will drive the quality of the final project results.

6.7.6. Status Reporting

You should identify the procedures you want the IT project team to use to report project and task status. It's important that you decide what information will help you know the project is on track. Think back to our discussion about the flexibility grid and the concept of precision or rigor. If budget is the least flexible element, your status reporting should clearly contain information about the budgetary items such as the actual versus estimated cost of each task or deliverable. If time is your most flexible element, you may not have the team track the time spent on the project down to the minute, but instead ask that time be rounded to the nearest hour or even half day.

There are several keys to effective status reporting:

1. The process for reporting status should utilize existing tools.

2. The status report should include data that already exists or is easy to compile, such as tasks completed, tasks underway, dollars spent, etc..

3. The reporting process should be well defined and should only ask for data that will help you manage the project.

4. The reporting process should not take long to complete from data gathering to reporting.

The adage "You get what you measure" certainly holds true here. The information you request in a status report is what your IT team will focus on because they'll have to report on it. Human nature being what it is, your team will strive to report positive results on the things they have to report, so they'll work hard to make sure they can report positive things. If you're measuring or monitoring the wrong things, your IT team will probably focus on those wrong things and your results won't be quite as good or on target as you'd like. Also avoid re-creating systems that are already in place. For instance, if your company has a process for people reporting their time for payroll processing, you may not need an additional time tracking tool. Look for ways to leverage existing systems before creating or adding new systems.

6.7.6.1. What To Report

Another truth about reporting is that if it is too difficult, too cumbersome, or takes too much time to complete, your team may very well "guesstimate" rather than take the time and effort to complete the status report accurately. If it takes too much effort, people will often forego accuracy (and sometimes truth) in order to just get the report done. If you've taken time to really think about what you need to know and how your team needs to report that, you can find the least amount of reporting that will keep you well informed. Some companies use exception-based reporting, meaning that they only want to know about work or tasks that are exceptions to the plan. If a task starts late or is running over budget, that would be reported. If a task is on time, has completed within budget, and is otherwise normal it would not be reported.

It's also important to sit down with your project sponsor and find out what kind of reporting he or she will need. Status reporting is the process of the team reporting to you, the IT project manager. However, you'll also have to report on the project status to your project sponsor and perhaps to other key executives. Reporting to your project sponsor may be a regular weekly report, for example, and reporting to key executives may well fall under the heading "Communications Plan" discussed later in this section. Many IT project managers find it helpful to develop a list of key metrics or data that fits with the flexibility and precision decisions made earlier with the sponsor and use those as the basis for discussion. If you ask the project sponsor an open-ended question such as, "What information on the project would you like to know about?" the response you receive can run the gamut from very little to everything. If your project sponsor's work style falls in the doer category, he or she may simply want to know that the project is on track and if there are any major problems. If your project sponsor's work style falls in the analyst category, he or she may ask for so much detail that you're running around preparing reports instead of actually managing the project. Rather than start with a "blank sheet of paper", start the discussion with your suggestions and ask the project sponsor to add or remove items. You'll end up with a more focused, useful list of items on which you'll need to report. It will also be another good opportunity to make sure your expectations are in line with your project sponsor's.

6.7.6.2. How To Report

You (and possibly your IT project team) should determine how the status reports will be generated and delivered. If you're using a project management software tool, you can use the tools and functionality within the tool to help your team develop and deliver reports based on data in the tool. However, not all PM tools have the same reporting capabilities. For instance, many users of Microsoft Project complain that it's very difficult to print just the data they want. If it's in a canned report it's fine, but if not, it can be difficult to generate meaningful reports. Other programs have limitations and you should try to avoid having the team jump through hoops to get data out of the PM tool for reporting. Some companies want hard copies of status reports, while others keep them as soft copy files on a server. Whatever method you use, make sure that everyone on your IT project team have access to the same reporting tools. If everyone but the three remote team members have access to a particular program, those three remote team members will not only be out of the loop, but they'll also have to do extra work to comply with reporting requirements. Make sure that if you use any technology for reporting that all team members have equal access or that you make specific accommodations to address any shortfalls.

6.7.6.3. When To Report

Another question you'll need to answer is how often you need status reports. Remember that more frequent milestones or checkpoints are important to a successful project, so it makes sense that frequent reporting can also contribute to a project's successto a point. You should determine the best reporting interval based on the complexity and scale of the project as well as your company's typical reporting cycles. If you have to report to your manager or project sponsor every week, you may need to have your team update you each week. You might also decide (and get approval) to have your team update you every two weeks and you present an overview report each month. If your reporting interval is too frequent, IT project team members may "fudge" their reports because it would take too much time away from getting the project work done. You can discourage that by making the reporting interval frequent enough to ensure the project is on track, but not so frequent as to be a burden on you or the team.

Ideally, you, your IT project team, and your project sponsor should come to agreement on what has to be reported, how it has to be reported, and when it has to be reported. If you can have the team participate in this definition process, you may find that the things you were going to request are too difficult to report on regularly (due to the PM tool or other factors) or you may have overlooked something important that your team or project sponsor identifies. A collaborative approach can fine-tune the reporting process so it encourages and drives the project outcomes.

Cheat Sheet …
Reporting on Reports

Some project managers make reporting such a big deal that it becomes an end in itself. This would fall into the category of "process for process's sake", which is nothing more than the tail chasing the tiger. Create a list of things you think should be reported and take it to your team for verification, approval, or modification. Then, see if you can pare it down further. Ask yourself, "What will this information do for me?" or "What will I do with this information once I have it?" Some information may clearly be needed such as actual budget for each task or deliverable. However, there's lot of information you can ask for and have your team report on that will not help you manage the project toward success. If you can't clearly state what the information is and how you will use it, consider removing it from your list. Keep it lean and mean to encourage accurate, timely, and meaningful reporting. And don't confuse reporting with recording. You may want or require your team to record very detailed information about the project, but you may only request a small portion of that data in the form of a report. You need the detail as backup and as history, but you probably don't need all that detail in a report. Here's a staggering factoid: 80% of all documents filed (electronic or paper) are never touched again. If you think about that when looking at reporting requirements, you might well be able to pare things down.

6.7.7. Defect/Error/Issue Tracking

Despite your best planning efforts, you will have to have some method of tracking deviations from the plan, whether those show up in the form of defects, errors, or issues. We'll use the generic issue tracking to refer to all types of problem tracking in a project.

You and your IT project team should define the issue tracking process and identify procedures the team can use when these issues arise. At minimum, you should define:

1. What constitutes an issue?

2. How should the issue be reported?

3. How should the issue be tracked?

4. How should the issue be resolved?

6.7.7.1. What Constitutes An Issue?

Using a process similar to the one you developed when identifying success criteria, you can identify criteria to use to identify a problem or issue. Identify what constitutes an issue that should be reported versus normal bumps along the project road. Some issues get resolved by the person who is working on the task or deliverable. Other issues require team notification because they:

• Impact other tasks' start, finish or deliverables

• Impact the cost of the project

• Impact the project schedule

• Trigger one of the project risks

• Put the entire project at risk

There may be other categories you want to add, but you can use this list as a starting point. Once you've identified the criteria that will be used by the team to identify reportable issues (versus issues that are handled quickly and easily within the project or even the task), the team will have a clear sense of what has to be reported and what doesn't. Once the project gets underway, you may find you have to modify these criteria to adjust to the reality of your project work, but the initial definition will help you and the team with a starting point.

The IT Factor…
Starting From Scratch

In most instances, it's easier for people to respond to something than to create it from scratch. Developing the criteria for issue tracking is a good example. You may come up with a list of suggested criteria and present it to the project team so they can respond to it. This might save time and effort, and your project team will have the opportunity for input without the burden of creating the original list. Responding to something usually takes less time and effort than creating it from scratch. Giving people the option of providing input for changes is often a better use of time than trying to "design by committee."

6.7.7.2. How Should the Issue be Reported?

Once your team understands what has to be reported, you'll also have to develop a procedure for reporting issues. First, how much information should be reported about an issue? Do you want an issue report form or just a list of items to include in the report? A quick issue report might include items such as issue title, brief description, person reporting, reporting date, and the task it is associated with. A lengthier report might include a longer description, how the issue was discovered, what the potential impact is (high, medium, or low criticality) and suggested resolution, as an example. You'll also need to ask and answer questions such as: Are issues reported to the team via e-mail or via their periodic status reports? Should critical issues be reported differently than non-critical issues? Should the entire team be notified of an issue or just the project manager? Identify the methods the team will use to report issues. Again, you want to avoid flooding the entire team with constant issue reports that don't pertain to them, but you also want the team in the loop on issues that may impact them or that impact the entire project. If you're using technology for these issue notification, make sure all members of your project team have equal access to these tools and know how to use them.

6.7.7.3. How Should the Issue be Tracked?

Once issues are identified and reported, how will they be tracked? Will you, as the IT project manager, manage that process? Will that task be assigned to a member of the team? Will the task be tracked in a software tool such as a Microsoft Word document, Excel spreadsheet, or Access database? Will issues be given a unique tracking number and if so, what is that number based upon? Will issues be tied to tasks or to the resource (person) performing the task? Again, less is more, so keep the tracking methods short and simple. Also make sure you have a system in place to avoid losing track of issues. Issue tracking is a key metric directly related to the health of the project. Tracking and managing issues also helps keep the team focused on the important problems. At the end of the project, as part of the close out we'll discuss toward the end of this book, you'll need to review all issues and ensure they were either resolved or closed. Any open issues at the end of the project should be reviewed and addressed (hint: some issues become irrelevant and are simply closed or left unresolved at the end of the project, but we'll discuss that in detail later).

6.7.7.4. How Should the Issue be Resolved?

Finally, what is the process for resolving issues? As you'll learn when we start assigning tasks, a task without an owner doesn't get done, and a task with two or more owners usually doesn't get done. The rule: one task, one owner. The same holds true for issues. If you feel like you need to assign more than one person to an issue, you might want to break the issue into its components and assign each component to an individual. This way you avoid the old finger-pointing routine or the honest confusion that comes from, "Sorry, I thought Lisa was handling that." Issue resolution not only requires an owner, it requires a deadline. Issues without deadlines rarely resolved. If possible, identify the completion criteria for the issue resolution as well. Completion criteria, which we'll discuss later when we discuss our work breakdown structure, are the criteria you develop so you'll know in a very clear and unambiguous way that the task was completed satisfactorily. These can also be developed for issue resolution. Sometimes the resolutions (or completion criteria) are unknown, but you can to develop these criteria as you go along. For instance, if a developer is working on a section of code and discovers that it will not integrate into the existing code in the manner that was specified or assumed, you have an issue to resolve. What would resolve this issue? The developer might have a few suggestions that can be included in the issue. For instance, she might suggest that an additional piece of code could be spec'd out to integrate these two elements or that the specifications for the code she's writing be revised to include code that will integrate these components. Often the person closest to the issue has the most realistic ideas about how the issue can be resolved, so encourage task owners or those working on the task to provide their input. Also keep in mind that it is possible for someone to be too close to a problem to see the solution, so sometimes the person closest to the issue is the most stumped for an answer (or has a vested interest in a particular solution) and you may have to turn to other subject matter experts for advice, input, or assistance.

6.7.8. Escalation Procedures

Escalation procedures should be put in place before problems arise, which is why you should define them at this point in your project. There are several types of escalation and each procedure should be clearly defined.

6.7.8.1. Issue Escalation

Members of your team should have a clearly defined escalation procedure to use to raise critical problems. If the procedure is clearly defined, team members don't have to think too hard to figure out how and when to escalate an issue. While your team members may be bright, motivated people, you want to minimize the amount of time and effort they expend on project tasks that don't drive the project forward. Work with your team to identify how and when issues should be escalated. If you've identified which types of things constitute issues (see the previous section) and what priority these issues are, then you're halfway to defining when to escalate an issue. Use clear, binary types of decision points. If you leave too much gray area, it will either cause confusion for the team or you risk having each team member interpret the guidelines differently.

6.7.8.2. Team Problem Escalation

You should also define how team members should resolve and escalate problems between team members. Whenever two or more people work together, the possibility for interpersonal conflict pops up and you should have clearly defined procedures for team members to escalate issues about the team itself. It's important to instill in the team members a sense of responsibility to the team so it can function at its best. Part of functioning well is addressing problems when they arise, and providing an easy-to-use escalation process for interpersonal problems will make sure that team members feel they have an outlet for resolving issues they cannot resolve on their own. As IT project manager, your job is to ensure the successful completion of the project and part of that is clearing away roadblocks to success.

6.7.8.3. Project Problem Escalation

Sometimes there is a problem with team members or with the project itself that are outside your area of influence or control. In these cases, you should define a project problem escalation procedure and run it by your project sponsor. As you know, the IT project manager often has to manage without organizational authority. That means that you have no direct control over project team members other than to try to influence them to complete their tasks or project work on time, on budget, and with the required quality. What if they fail to do that? What if they are falling behind and putting the project at risk? What if they are simply unable to deliver? What should you do? Since your job is to shepherd the project along toward successful completion, you may also need an escalation path to someone in the organization with the authority to resolve higher-level issues. That person might be your project sponsor or it might not be, but often the escalation path goes through the project sponsor for issues that you're unable to resolve through normal processes.

In additional to potential personnel issues that might impact your project, there may also be issues with the project itself that should be escalated. This might be a key vendor failing to deliver due to a payment dispute with your corporate finance folks or a key part of the project failing initial tests. Sit down with your project sponsor and identify the types of issues that should be brought to him or her for resolution. Some project sponsors are fairly hands-on and might want you to bring all issues with high or medium criticality to their attention immediately. Others might want a weekly or monthly report. Still others might tell you to only come to them when all other options fail. You'll need to develop an explicit understanding with your sponsor about escalating issues (how, what, when, where, why, who) so there are no misunderstandings. No one likes unhappy surprises and project sponsors are no exception. You know how much you hate being taken by surprise, so make sure you keep your project sponsor up to date by agreeing, in advance, on escalation procedures.

6.7.9. Documentation Procedures

As you've gone through the last couple of chapters, you've seen the document icon we're using to indicate when you have a tangible document as the outcome. Examples include user requirements, acceptance criteria, and the initial project proposal. All of these are examples of project documentation. Each company may have its own procedures regarding how to document a project and if yours has defined procedures, feel free to use them. Otherwise, work with your project team to define what has to be documented and why. Just like status reports, you may not need to document every last detail (then again, you may need to), and you should only document what's going to be useful in the future. Remember that there may be legal, ethical, or corporate requirements about documentation for your project and you should clearly adhere to those requirements. If nothing like that exists, think about which information will be useful to you or someone during and after the project, then decide how that information should be captured and documented.

Keep in mind that documentation can be useful during the life of the project for figuring out what was done when and by whom, but it can also be helpful later when quality testing or troubleshooting issues. Keeping thorough (but relevant) records may also end up being a very useful tool after the project is complete.

6.7.10. Approval Procedures

In an ideal world, the IT project manager would have full authority over the project, including the authority to approve the schedule, allocate resources, and spend money. In the real world, the amount of authority given to the IT project manager varies widely. At minimum, you should have the authority to get the project done without constantly going back to the project sponsor for approval. If that ends up being the case, the project sponsor may not clearly understand his or her role versus your role as IT project manager. If the project sponsor trusts you to run the project, he or she should also trust you, within certain guidelines, to make decisions for the project. In most situations, IT project managers have enough authority to make routine expenditures and decisions for the project and are required to go to their project sponsor for approval for unusual or large decisions.

Before heading into your project, get agreement from your project sponsor as to what does and does not require project sponsor approval. If possible, negotiate for a reasonable amount of autonomy to make scheduling, resource, and budget decisions. For budget expenditures, most companies have set rules regarding what level of expenditure requires additional approval. If those are too low for your project, make the business case for raising that limit for the project. For example, suppose your company has a limit of $500 for any single expenditure before getting higher-level approval. Suppose your IT project involves replacing all of the corporate servers, each of which you estimate to cost between $800 and $3,000. Every time you prepare to purchase a new server, your current guidelines would require you to get approval. You could be strangled by corporate red tape even before you purchase your first server. You may want to build this level of fiscal authority into the project plan itself so that within the initial project proposal you state that all expenditures for servers up to $3,000 per server will be allowed and other expenditures above $500 will go through the approval process (or whatever reasonable solution works for you). Pre-negotiate these items so your project doesn't get bogged down later on with budget review and exception requests.

6.7.11. Deployment Plan

Developing a deployment plan may be part of your project's deliverables, but it might be overlooked if someone outside your IT project team is responsible for deployment activities. In many software companies, especially enterprise-level software, the deployment is handled by a specialized deployment team. In other companies, the IT team is the one that does the deployment. If necessary, form a deployment team and make sure you invite key users (typically handpicked subject matter experts) to participate in developing the deployment plan since it will directly impact users. If you don't involve users in developing the deployment plan, there's a good chance you'll make incorrect assumptions, disrupt operations, and have a whole group of people really cranky with you and the IT team. It's much easier to bring the right people together to develop the plan, gain their buy-in, utilize their expertise, and develop a plan that meets the needs of both the IT project team and the users.

6.7.12. Operations Plan

After the project is complete and deployed, will you also need to operate or maintain the project's deliverables? For instance, if your team is responsible for developing Web content for a client, will you also be expected to maintain that content? If so, you need a post-project operations plan that delineates what has to happen next. Clearly the operations plan will be specific to each type of project and deliverable, so guidelines here won't be of too much help. However, you can use your IT project management process to create a project plan for the operations plan. Sound redundant? It's not really. If a project is, by definition, a unique solution to a unique problem, then you can use PM to solve the problem of "How do we maintain the operations of the project after it's been completed and deployed?"

6.7.13. Training Plan

The training plan is listed last, but it shouldn't be the last thing you think of at the end of your project. One of the most common criticisms of IT departments is that they don't think about training until it's too late or they assume it's someone else's job. Even if delivering the training is someone else's job, you should begin to define what will be needed by the trainers when you hand this project off to them. The easiest way to create your training plan may be to invite the key training staff to a meeting and ask them what they'll need and when. If training is up to you, you'll need to answer those questions with the user in mind, not with the IT project schedule in mind. User training can be accomplished in numerous ways and finding the most effective training methods, both in terms of the cost of training and the effectiveness for the user, is important. If you wait until the project is winding down to think about training, you're doing yourself, your team, and your project a disservice because the user perception of the project will be negatively impacted as will their actual experience. As with your operations plan, you may choose to create a separate sub-project plan that goes through all the IT PM steps to create a training plan. As you've probably already figured out, these IT PM steps are highly scalable, so you can use it for large and small projects alike. Using the same IT PM process for all your projects reinforces your skills and provides a consistent approach that everyone will appreciate, especially as they become more and more familiar with the IT PM components. A good place to start with training elements is with the project's requirements. This helps identify who might need training and what elements will be included in training.

Enterprise 128 …
People, Technology, and Business

When you're developing your processes and procedures, keep in mind that all IT projects involve people, technology, and business. Make sure your processes address or accommodate these three elements. If you forget about people or business in favor of technology (the most common thing IT project managers do), your project will start to wobble. Your processes and procedures should conform to your business's requirements; they should help people get the project done quickly and efficiently (and ideally, reduce the amount of work people have to do). Once you've got those two bases covered, you can concern yourself with processes and procedures involving technology. Saving the best for last (from an IT perspective) will help you remember to address the first two.

Figure 6-10. Project Processes and Procedures

If you refer to Figure 6.11 (the same as Figure 6.2 earlier in the chapter), you can see that the output from the steps described here in Chapter 6 is an initial project plan that you should bring to your project sponsor for approval. Approval includes verifying the information and assumptions included in the project as well as giving you the green light for moving on to the next phase of your IT project planning process. You should have steps 1, 2, and 3 completed. Once you have approval from your project sponsor (steps 4 and 5) you can move on to step 6, which we'll discuss in Chapters 7 and 8.

Figure 6-11. Initial Project Plan Approval

Cheat Sheet…
The Genesis of Problems

It's been said that many problems are born from solutions. If you think about that, it means that often when we think we're solving a problem, we're creating new problems. While we can't always avoid creating new problems, we can certainly reduce the number or magnitude of new problems by taking time to make sure we're solving the right problem in the right way. The steps we've reviewed in Chapter 5 and Chapter 6 will help you make sure you're solving the right problem in the best way possible. Everything we do from here on out will build upon the foundation we've built in these two chapters, so now's the best time to step back and make sure you are comfortable with what you've developed so far. If not, make a few tweaks so your project actually solves more problems than it creates.