Learning Objectives

• Describe the five project management process groups, the typical level of activity for each, and the interactions among them
• Understand how the project management process groups relate to the project management knowledge areas
• Discuss how organizations develop information technology (IT) project management methodologies(方法）to meet their needs
• Review a case study of an organization applying the project management process groups to manage an IT project, describe outputs of each process group, and understand the contribution that effective initiating (项目启动), planning, executing, monitoring and controlling, and closing make to project success
• Review the same case study of a project managed with an agile focus to illustrate（说明） the key differences in approaches
• Describe several templates （模版） for creating documents for each process group

Project Management Process Groups

• A process is a series of actions directed toward a particular result
• Project management can be viewed as a number of interlinked （互相关联的） processes
• The project management process groups include
  • initiating processes
  • planning processes
  • executing processes
  • monitoring and controlling processes
  • closing processes

Level of Activity and Overlap(重叠) of Process Groups Over Time

image.png

image.png

Project Management Process Groups and Knowledge Area Mapping （映射） *

image.png

image.png

image.png

image.png

image.png

Developing an IT Project Management Methodology

• Just as projects are unique, so are approaches to project management
• Many organizations develop their own project management methodologies, especially for IT projects
• A methodology(方法)[ideas or processes or procedures] describes how things should be done; a standard[rules or guidelines] describes what should be done
• PRINCE2, Agile, RUP, and Six Sigma provide different project management methodologies

IT Project Management Methodology

image.png

image.png

image.png

image.png

image.png

image.png

image.png

What is INTRANET?

• An intranet is a private network accessible only to an organization's staff.
• Generally a wide range of information and services from the organization's internal IT systems are available that would not be available to the public from the Internet.

What is Extranet?

• An intranet that can be partially accessed by authorized outside users, enabling businesses to exchange information over the Internet in a secure way.

Project Pre-initiation

• It is good practice to lay the groundwork(打好基础) for a project before it officially starts
• Senior managers often perform several pre-initiation tasks, including the following:
  • Determine the scope, time, and cost constraints for the project
  • Identify the project sponsor
  • Select the project manager
  • Develop a business case(商业论证) for a project (see Table 3-2 for an example)
  • Meet with the project manager to review the process and expectations for managing the project
  • Determine if the project should be divided into two or more smaller projects

Business Case(商业论证) -Document

• A business case captures the reasoning(论证) for initiating a project or task.
• It is often presented in a well-structured written document.
• The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a specific business need.
• Notice that the following information is included in this business case:
  • Introduction/background
  • Business objective
  • Current situation and problem/opportunity statement
  • Critical assumptions and constraints
  • Analysis of options and recommendation
  • Preliminary(初步的) project requirements
  • Budget estimate and financial analysis
  • Schedule estimate
  • Potential risks
  • Exhibits

Project Initiation

• Initiating a project includes recognizing and starting a new project or project phase
• The main goal is to formally select and start off projects
• Table 3-3 shows the project initiation knowledge areas, processes, and outputs

image.png

Project Charters (宪章) and Kick-off Meetings (启动会议)

• Charters are normally short and include key project information and stakeholder signatures(署名)
• It’s good practice to hold a kick-off meeting at the beginning of a project so that stakeholders can meet each other, review the goals of the project, and discuss future plans

image.png

image.png

Project Planning

• The main purpose of project planning is to guide execution
• Every knowledge area includes planning information (see Table 3-7 on pages 101-102)
• Key outputs included in the JWD project include:
  • A team contract
  • A project scope statement
  • A work breakdown structure (WBS)
  • A project schedule, in the form of a Gantt chart with all dependencies and resources entered
  • A list of prioritized (有优先级的) risks (part of a risk register)
• See sample documents starting on p. 104

Project Planning – WBS (Work break Down Structure)

Project Baseline Gantt Chart

List of Prioritized Risks

Project Executing

• Usually takes the most time and resources to perform project execution.
• Project managers must use their leadership skills to handle the many challenges that occur during project execution
• Table 3-11 on p. 111 lists the executing processes and outputs. Many project sponsors and customers focus on deliverables related to providing the products, services, or results desired from the project
• A milestone report (example on pp. 112-113) can help focus on completing major milestones

image.png

image.png

Project Monitoring and Controlling

• Involves measuring progress toward project objectives, monitoring deviation (偏离) from the plan, and taking correction actions
• Affects all other process groups and occurs during all phases of the project life cycle
• Outputs include performance reports, change requests, and updates to various plans
• See Table 3-13

image.png

image.png

image.png

Sample weekly progress report (每周进度报告)

Project Closing

• Involves gaining stakeholder and customer acceptance of the final products and services
• Even if projects are not completed, they should be closed out to learn from the past
• Outputs include project files and lessons-learned (经验教训) reports, part of organizational process assets
• Most projects also include a final report and presentation to the sponsor/senior management

image.png

image.png

What is Scrum?

• Scrum is a lightweight agile project management framework mainly used for software development.
• It describes an iterative and incremental approach for project work.

image.png

• Scrum can be used in all kinds of software development:
  • for developing complete software packages, for developing only some parts of bigger systems, for customer or internal projects.
• The Scrum Framework implements the cornerstones defined by the agile manifesto:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
• The main components of Scrum Framework are:
  • The three roles: Scrum Master, Scrum Product Owner and the Scrum Team
  • A prioritized Backlog containing the end user requirements
  • Sprints
  • Scrum Events: Sprint Planning Meeting (WHAT-Meeting, HOW-Meeting), Daily Scrum Meeting, Sprint Review Meeting, Sprint Retrospective Meeting
• Important in all Scrum projects are self-organization and communication within the team. There is no longer a project manager in a classical sense.
  • In the Scrum Framework the Scrum Master and the Scrum Product Owner share his responsibilities.
  • However, in the end the team decides what and how much they can do in a given project iteration (Sprint).
• Another central aspect within the Scrum Framework is continuous improvement: inspect & adapt.
• The Scrum Teams have to frequently inspect and assess their created artifacts and processes in order to adapt and optimize them.
• In the midterm this will optimize the results, increases predictably and therefore minimize overall project risk.
• The Scrum Framework tries to deal with the fact that the requirements are likely to change quickly or are not completely known at the start of the project.
• The low-level requirements are only defined at the time when they are going to be really implemented.
• In Scrum, changes and optimizations of product, requirements and processes are an integral part of the whole engineering cycle.
• Another cornerstone of the Scrum Framework is communication.
  • The Scrum Product Owner works closely with the Scrum Team to identify and prioritize functionality.
  • This functionality is written down in user stories and stored in a Scrum Product Backlog.
  • The Product Backlog consists everything that needs to be done in order to successfully deliver a working software system.
• The Scrum Team is empowered to only select the user stories they are sure they can finish within the 2-4 weeks of Sprints. As the Scrum Team is allowed to commit their own goals they will be more motivated and work with best possible performance.
• The Scrum Master is another important role in the Scrum Framework as it works as a servant-master with the Scrum Team. His/her main tasks are to make the Scrum team understand how Scrum operates, to protect the Scrum Team from external interruptions and to remove impediments that hinder the Scrum Team to reach its maximum productivity.

image.png

image.png

image.png

What Makes Waterfall Software Development Model Fail in Many Ways?

• When deploying the waterfall methodology there is a strict sequential chain of the different project phases.
• A previous phase has to be completed before starting the next phase. Going back is in most cases difficult, costly, frustrating to the team and time consuming.

image.png

• The project timeline is planned at the start. A releasable product is delivered only at the end of the project timeline. If one phase is delayed all other phases are also delayed.
• To avoid this users of the waterfall methodology normally try to anticipate all possibilities beforehand.
• Studies have shown that in larger and complex projects about 60% of the initial requirements are changed throughout the project.
• The waterfall approach for developing software can be used for implementing small and simple projects.

What Makes the Scrum Framework Succeed?

• The Scrum framework changes the classical triangle of project management. The compromise is no longer between Time, Budget and Quality. It is now becoming the triangle of Budget, Time and Functionality.
• Quality is no longer an option. In Scrum the factors that define when a feature is complete (in terms of quality, required testing, documentation etc.) are defined by the Definition Of Done (DoD) right at the start of the project.

image.png

• Studies have shown that Scrum has following positive effects in practice:
  • Increased productivity
  • Better product quality
  • Reduced or stable project costs after introducing agile methods
  • Higher customer satisfaction
  • Increased satisfaction and motivation of the employees

Scrum Roles - The Scrum Team

• Within the Scrum Framework three roles are defined:
  • The Scrum Team
  • Scrum Master
  • Scrum Product Owner
• Each of these roles has a defined set of responsibilities and only if they fulfill these responsibilities, closely interact and work together they can finish a project successfully.

The Scrum Team

• Within the Scrum Framework all work delivered to the customer is done by dedicated Scrum Teams. A Scrum Team is a collection of individuals working together to deliver the requested and committed product increments.
• Scrum Teams are small.
• The ideal size is 7 +/- 2 people.

The Scrum Master

• Broad speaking it is the job of the Scrum Master to ensure that the Scrum Team adheres to the Scrum theory, practices and rules.

Scrum Product Owner

• The Scrum Product Owner is a central role within the Scrum Framework. Most of the responsibilities of the classical product manager and the project manager are combined within this single role.��He represents the end customer and/or other stakeholders and is responsible for maximizing the value of the product by ensuring that the right work is done at the right time.��As a consequence this means of course that the Scrum Product Owner has to work very closely with the Scrum Team and coordinates their activities over the whole lifetime of the project. No one else is allowed to tell the development team to work from a different set of priorities.
• The Scrum Product Owner has a number of responsibilities:
  • Managing the Scrum Product Backlog
  • Release Management
  • Stakeholder Management
  • Work closely with the Scrum Team

The Scrum Product Backlog

• In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project.
• It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories. The owner of the Scrum Product Backlog is the Scrum Product Owner.
• The Scrum Master, the Scrum Team and other Stakeholders contribute it to have a broad and complete To-Do list.
• Each Scrum Product Backlog has certain properties that differentiate it from a simple to-do list:
  • an entry in the Scrum Product Backlog always add value for the customer
  • the entries in the Scrum Product Backlog are prioritized and ordered accordingly
  • the level of detail depends on the position of the entry within the Scrum Product Backlog
  • all entries are estimated
  • the Scrum Product Backlog is a living document
  • there are no action-items or low-level tasks in the Scrum Product Backlog

image.png

Scrum User Stories

• The entries in the Scrum Product Backlog are often written in the form of User Stories.
• A User Story tells a short story about someone using the product. It contains a name, a brief narrative, and acceptance criteria and conditions for the story to be complete.
• The advantage of user stories is that they focus on exactly what the user needs/wants without going into the details on how to achieve it.

image.png

Scrum Effort Estimations

• All the entries within the Scrum Product Backlog have to be estimated to allow the Scrum Product Owner to prioritize the entries and to plan releases. This means that the Scrum Product Owner needs an honest assessment of how difficult the work will be. Nevertheless it is recommended that the Scrum Product Owner does not attend the estimation to avoid pressuring (intentionally or otherwise) the Scrum Team.��The Scrum Framework itself does not prescribe a single way for the Scrum Teams to estimate their work. However within the Scrum Framework the estimation is not normally done in terms of time - a more abstracted metric to quantify effort is used. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL) or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.).

What is a Sprint?

• In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed within Sprints (also called 'Iterations'). Sprints are always short: normally about 2-4 weeks.��Each Sprint follows a defined process as shown below:

image.png

• Each Sprint start with two planning sessions to define the content of the Sprint: the WHAT-Meeting and the HOW-Meeting.
• The combination of these two meeting are also defined as Sprint Planning Meeting.
  • In the WHAT-Meeting the Scrum Team commits to the User Stories from the Scrum Product Backlog and
  • It uses a HOW-Meeting to break the committed User Stories into smaller and concrete tasks. Then implementation begins.
• At the end of the Sprint a Sprint Review Meeting is conducted to allow the Scrum Product Owner to check if all of the committed items are complete and implemented correctly. Additionally a Sprint Retrospective Meeting is conducted to check and improve the project execution processes: What was good during the Sprint, what should continue as it is and what should be improved.
• During the Sprint a short daily Standup-Meeting (Daily Scrum Meeting) is held to update the status of the items and to help self-organization of the team.

Scrum Burndown Chart

The Scrum Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule.

image.png

• The rate of progress of a Scrum Team is called "velocity".
• It expresses the amount of e.g. story points completed per iteration.
• An import rule for calculating the velocity is that only stories that are completed at the end of the iteration are counted. Counting partially finished work (e.g. coding only - test missing) is strictly forbidden.

Sprint Planning Meeting

• Each Sprint and each Sprint Planning Meeting starts with a WHAT-Meeting.
• Goal of this session is to define a realistic Sprint Backlog containing all items that could be fully implemented until the end of the Sprint.

The Sprint Backlog

Within the Sprint Backlog all activities required to complete the committed entries from the Scrum Product Backlog are stored. All entries have to be estimated on a person-hour base in order to track progress and remaining efforts.

image.png

Sprint Burndown Reports / Charts

The Sprint Burndown Report shows the progress within the Sprint toward reaching the Sprint Goal. It provides transparency about the current performance (burndown rate) and allows easy estimation if the Sprint Goal can be reached in time or if the team has to find additional measures to speed-up completion of the remaining activities.

image.png

Daily Scrum Meeting / Daily Stand-up Meeting

• The daily Scrum meeting is a short everyday meeting, ideally during start of the working day. Each team member who works towards the completion of a given sprint needs to participate.
• During this meeting, each team member should briefly provide the answers of the following three questions:
  • What has he/she accomplished since the last daily Scrum meeting?
  • What is he/she is going to accomplish until the next Scrum meeting?
  • What are the impediments that prevent he/she from accomplishing his/her tasks?
• All team members should attend and they should stand during the meeting. The daily Scrum meeting should ideally not last more than 15 minutes.
• On the other no issues or concerns raised during the meeting are allowed to be ignored due to the lack of time. Issues or concerns ought to be recorded by the Scrum Master and needs to be specifically handled after the meeting.

Sprint Review Meeting

At the end of each sprint a Sprint Review meeting is held. During this meeting the Scrum Team shows which Scrum Product Backlog items they completed (according to the Definition of Done) during the sprint. This might take place in the form of a demo of the new features.

Sprint Retrospective Meeting

• After the Sprint Review meeting took place the Scrum Team and the Scrum Master get together for the Sprint Retrospective.
• In this meeting all team members reflect on the past sprint and check three things: what went well during the sprint, what didn't, and what improvements could be made in the next sprint. The meeting should be time-boxed (e.g. 3 hours).

Scrum Release Planning

• Releases can be intermediate deliveries done during the project or the final delivery at the end.
• To create a Release Plan the following things have to be available:
  • A prioritized and estimated Scrum Product Backlog
  • The (estimated) velocity of the Scrum Team
  • Conditions of satisfaction (goals for the schedule, scope, resources)
• If the project is feature-driven, the sum of all features within in a release can be divided by the expected velocity. This will then result in the number of sprints needed to complete the requested functionality.

image.png

Pictorial representation of Waterfall, Iterative and Scrum Software Development methodologies.

An Informed(明智的) Decision

• It is not a snap decision(仓促决定) whether to use an agile approach or not, just like flying or driving somewhere on a trip
• Projects with less rigid(严格的) constraints, experienced and preferably(更适宜) co-located(同地协作的) teams, smaller risks, unclear requirements, and more flexible scheduling would be more compatible with an agile approach
• The following example uses Scrum roles, artifacts, and ceremonies

Scrum Roles

• Product owner: The person responsible for the business value of the project and for deciding what work to do and in what order, as documented in the product backlog (积压待办的工作).
• ScrumMaster(PM): The person who ensures that the team is productive, facilitates the daily Scrum, enables close cooperation across all roles and functions, and removes barriers(障碍) that prevent the team from being effective.
• Scrum team or development team: A cross-functional team of five to nine people who organize themselves and the work to produce the desired results for each sprint, which normally lasts 2-4 weeks.

Scrum Artifacts

• An artifact is a useful object created by people
• Scrum artifacts include:
  • Product backlog: A list of features prioritized by business value
  • Sprint backlog(冲刺订单): The highest-priority items from the product backlog to be completed within a sprint
  • Burndown chart(竣工情况图): Shows the cumulative（渐增的）work remaining in a sprint on a day-by-day basis

image.png

Scrum Ceremonies

• Sprint planning session: A meeting with the team to select a set of work from the product backlog to deliver during a sprint.
• Daily Scrum: A short meeting for the development team to share progress and challenges and plan work for the day.
• Sprint reviews: A meeting in which the team demonstrates to the product owner what it has completed during the sprint.
• Sprint retrospectives(回顾): A meeting in which the team looks for ways to improve the product and the process based on a review of the actual performance of the development team.

image.png

unique Scrum Activities by Process Group

image.png

Chapter Summary

• The five project management process groups are initiating, planning, executing, monitoring and controlling, and closing
• You can map the main activities of each process group to the nine knowledge areas
• Some organizations develop their own information technology project management methodologies
• The JWD Consulting case study provides an example of using the process groups and shows several important project documents
• The second version of the same case study illustrates differences using agile (Scrum). The biggest difference is providing three releases of useable software versus just one