Microsoft Project Fundamentals. Teresa S. Stover
Читать онлайн книгу.
the signatures of responsible project stakeholders, especially the project sponsor and project manager. When the project charter is completed and signed, the project manager can move forward with budget and other resource authorization to start project planning and execution.
Drafting the project charter ensures that the project is not left to assumption or chance. As the project springboard, it's the first step in communicating expectations with your boss, the customer, or other project sponsor.
Start Planning
With authorization in hand, you can now take the time to drill down and detail the project requirements and scope that are broadly outlined in the project charter.
If you haven't done so already, this is the right time to decide whether the project will follow the agile or the waterfall project management methodology (refer back to Lesson 1, “Project Management Basics”). Which one you choose will determine how detailed your requirements and scope must be.
Then, after you finish the initiating process, your chosen methodology will determine how you'll build the project and how you'll use Microsoft Project beginning in Lesson 4, “Set Up the Project and Tasks.”
Collect Requirements
Your project typically develops a new product, service, or other result. Requirements specify the condition or capability that a product or service must achieve in terms of function, features, technical specifications, quality standards, performance, or other characteristics.
In addition to product requirements, you have project requirements like the all-important total cost and finish date. By defining both types of requirements, you are managing customer expectations as well as gathering the information you'll need to develop the project's work breakdown structure (WBS) as the list of requirements become the focus of the project work.
Developing detailed requirements before starting the project is essential in a waterfall project. However, because of the agile project's nature of exploration and discovery, requirements can be broader and loosely defined, more as a starting point. Requirements are defined and reprioritized throughout the course of multiple project sprints, deliverables, and feedback loops.
In either case, identifying requirements is key to project success, because the final outcomes of the project are measured against the defined requirements. In the majority of projects that exceed budget or schedule, that are canceled, or that otherwise fail to meet their goals, the reason tracks back to issues relating to requirements.
The first step is to gather a list of potential requirements. Consider the following to tease out requirements with users and other stakeholders:
Brainstorming
Interviews
Questionnaires
Reviewing existing documentation
Observing end users in their relevant tasks
Mapping the as-is state for the existing product or service
Prototyping
You might find prototyping an especially valuable deliverable in either an agile or a waterfall project. Whether it's a small-scale product, mockup, or simulation, you can present prototypes to your stakeholders at strategic points of a project to validate the requirements and make decisions and adjustments accordingly.
After you develop the list of requirements, work with your stakeholders to review and prioritize the requirements. A good method is to work with the group to reach consensus on the highest-value requirements. Then together rank those requirements in their priority order. This way, you and your stakeholders can finalize the requirements that will drive this project.
Define the Scope
Whereas the project charter is a high-level project overview that authorizes project implementation, the project scope is a more detailed version of much of the same information, laying out the parameters of the project.
In a waterfall project, the scope defines the boundaries of a project, not only saying what the project will accomplish but also indicating what the project will not do. Articulating these boundaries is essential to preventing scope creep, a common problem for waterfall projects. Throughout a project, team members and managing stakeholders often see opportunities for innovations or enhancements related to the work being done. The temptation is great to include these changes, which often seem inconsequential and easy to manage. These small changes beyond the specified scope can gradually creep up and have a cumulative effect, which results in project delays and cost overruns. Defining the scope well and keeping a close eye on its boundaries throughout the project is a key to project management success.
In an agile project, on the other hand, scope is continually refined throughout the life of the project with its iterative sprints. Because scope is expected to change and adjust throughout an agile project, scope creep is not an issue.
While the project charter is finished and “locked in” as soon as it's signed and therefore authorized, the project scope is a living document. Expect to update the project scope as conditions change and decisions are made throughout the project life cycle.
The project scope should include the following:
Project Scope Specifies what is and is not included in the project. In this way, this section indicates the boundaries of the project.
Requirements Define the conditions that must be met for the project sponsor to accept the project's deliverables.
Deliverables List and describe all tangible or intangible goods or services produced for the project.
Project Constraints Indicate any limitations on the project such as time, money, or resources.
Assumptions Enumerate anything assumed but not definitely known about the project parameters.
The project scope statement defines the project's goals, requirements, and boundaries. It's typically presented to not only the project sponsor but also to the team leads and other project stakeholders as the “what” of the project. The “how” of the project is presented in the next step as the project plan and schedule.
Because the project scope defines the requirements and deliverables, it helps stakeholders determine where the project is in the process and whether the project is complete and has satisfied its objective.
Organize Project Plan Documents
You'll draft the project charter, stakeholders list, requirements, and project scope statement in a word processing document or other document outside of Microsoft Project. Determine who needs access to these key project planning documents and how best to organize and provide access. Here are some options:
Using a network drive that managing stakeholders have access to
Using a cloud drive (such as OneDrive or Google Drive) and giving stakeholders access
Creating a SharePoint site that contains all key project documents
Storing project documents as attachments to your project plan in Microsoft Project
To attach a document to a Project plan:
1 Open the Project plan.
2 If necessary, add the project summary task. On the Format tab, in the Show/Hide group, click Project Summary Task.The project summary