and influence others in support of the project.
Project Manager That's you—the person who is assigned the overall responsibility for planning, executing, monitoring, controlling, and closing the project. You set up and execute the project plan, secure and manage the project team and other resources carrying out the project tasks, track and report on progress toward deliverables and milestones, monitor costs, and adjust the project for changing conditions, all while moving toward a successful completion by the established finish date.
Managing Stakeholders These are leaders who have a management responsibility associated with the project. The project sponsor and project manager are two managing stakeholders, but there might be others. Examples might include department heads who are affected by the use of their team members on the project or who will review specific project deliverables.
Team Members Team members are those who will be assigned to project task responsibilities. You might not have a complete list at this stage, but you can identify names and job functions or titles, or just job functions or skill sets that will be required by the project. This information can help with high-level project and cost estimating.
Customers and End Users These are the people who stand to benefit from the results of the project. End users might (or might not) be directly consulted throughout the project. Either way, name them as a stakeholder category and consider developing customer profiles or user stories to keep their wants and needs in mind as you and the team work through the project.
Authorize the Project Charter
The project charter is like the project's mission statement. It's typically a two-page project overview document that concisely defines the project goal and other high-level parameters of the project.
The project charter formalizes the project, even in an informal organization. It can be invaluable to clarify when an organization executive or customer might have just been “thinking out loud” versus giving a real directive about a true commitment to a project.
Rather like an internal contract, the project charter names and authorizes the project manager and is signed by the project sponsor. The project charter can serve as the “North Star” when matters get murky.
Because the project charter is probably the first document generated for the new project, many unknowns are likely. Between this fact and the conciseness of the document, the more high level and broad the charter, the better it will serve everyone in the long run.
The project charter should include the following:
Project Goal States the purpose or business case justification of the project and characteristics of the product or service being produced.
Objectives List measurable objectives to meet the goal, along with a summary milestone schedule, including the overall project finish date.
High-Level Requirements Describe the characteristics of the end product or service and summarize the project requirements in terms of time, quality, and scope. This or a separate section might also list known project risks, constraints, or issues.
Project Outcomes Identify measurable success criteria to know when and whether the project has achieved its intended goal.
Overview Budget Can be a single overall expected budget total or identify high-level budget categories for the project.
Stakeholders Include the name, title, and responsibilities of the project sponsor and project manager, including their level of authority; managing stakeholders; project team members; and customers or end users.
Project Approval Requirements Identify any interim review and approval points during the project and final project acceptance and sign-off upon project close.
Project Charter Authorization Includes 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
