Section 6.8. Summary

6.8. Summary

In this chapter, we continued the process started in Chapter 5 by honing our project definition and by creating the project structure and framework. You should now have clearly defined project objectives, which are used as the project's major deliverables or are used to define the major deliverables. We spent quite a bit of time identifying and categorizing stakeholders. This often-skipped step is vital to a successful project because making sure the project meets the needs of users and the expectations of stakeholders is vitally important. Although the task of identifying all stakeholders can be a bit larger than you might at first have imagined, when you're finished, you'll know that you've likely included all the right people in the right ways.

With a complete list of project stakeholders, you can develop the project's requirements. To develop requirements before identifying all the relevant project stakeholders would simply mean you'd have to cycle through this process two or three (or more) times to refine requirements as you discovered or included new stakeholders or risk the project will not meet all perceived requirements. With a complete and categorized list of stakeholders, you can more easily manage the requirements gathering phase. Depending on the nature of the IT project, your project requirements will vary. You will also have to find a way to integrate or manage sometimes disparate requirements. Sometimes that means you have to negotiate with various stakeholders or work with them to agree on what might be removed or delayed so the project has a chance of success. Clearly defined, agreed-upon requirements is one of the most essential elements of a successful project and time spent on this step will pay for itself tenfold on the other end.

We reviewed a number of project parameters that you'll need to define for your project including success criteria and acceptance criteria. These help you define, in advance, what the project will look like when successfully completed and what it will take for clients to sign off on major deliverables. We also defined a number of other parameters such as the flexibility grid and the amount of precision needed for the project. These are needed when you have to make decisions regarding changes to the project later on. They help you make better, faster decisions that are aligned with the priorities of the company and the project sponsor. There are numerous other project parameters that you may want to define in order to bring clarity to your project early in the planning cycle.

Every project also requires infrastructure and this is as good a time as any to begin defining those elements. You'll need to decide what physical infrastructure needs you have such as office space, furniture, and phone lines. You'll also need to figure out your technology requirements from computers, network connections, network storage, cell phones, and PDAs to any special technology needs such as a testing lab or testing equipment. Also make sure that all the remote members of your team are as connected as those at the home office and that the remote staff have equal access to project resources.

Project processes and procedures, when well-designed, help reduce IT project team stress by providing simple, easy-to-use processes, procedures, and tools to help them manage the project workload. Consistent processes and procedures help everyone perform at a higher level, but there is a limit. Avoid creating processes and procedures that simply get in the way of getting work done. Encourage feedback from your team during the definition of processes and procedures as well as when the project is underway. Your job is to remove roadblocks for your team, not create them, so define only as many processes and procedures as will help. This varies from project to project and from company to company. If you have processes and procedures from previous projects, repurposing them can save you a lot of timedon't reinvent the wheel if you don't have to.