Professional, Intermediate, Novice User Guide for all of Us

Project Management Knowledge Areas

November 13th, 2008 chris

In project management, the process groups help you organize the processes by the kind of work you do. The knowledge areas help you organize by the subject matter you’re dealing with.

The nine knowledge areas of project management are:

  1. Project Integration Management
  2. Project Scope Management
  3. Project Time Management
  4. Project Cost Management
  5. Project Quality Management
  6. Project Human Resource Management
  7. Project Communications Management
  8. Project Risk Management
  9. Project Procurement Management

Project Management Process Groups

November 12th, 2008 chris

The Project Management Processes are aggregated into five groups, defined as the Project Management Process Groups:

  1. Initiating Process Group - Defines and authorizes the project or a project phase.
  2. Planning Process Group - Defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project was undertaken to address.
  3. Executing Process Group - Integrates people and other resources to carry out the project management plan for the project.
  4. Monitoring and Controlling Process Group - Regularly measures and monitors progress to identify variances from the project management plan so that corrective action can be taken when necessary to meet project objectives.
  5. Closing Process Group - Formalizes acceptance of the product, service or result and brings the project or a project phase to an orderly end.

Project Management Processes

November 12th, 2008 chris

The project management processes are presented as discrete elements with well-defined interfaces. However, in practice they overlap and interact in ways that are not completely detailed in theory. Most experienced project management practitioners recognize there is more than one way to manage a project. The specifics for a project are defined as objectives that must be accomplished based on complexity, risk, size, time frame, project team’s experience, access to resources, amount of historical information, the organization’s project management maturity, and industry and application area. The required Process Groups and their constituent processes are guides to apply appropriate project management knowledge and skills during the project. The application of the project management processes to a project is iterative and many processes are repeated and revised during the project. The project manager and the project team are responsible for determining what processes from the Process Groups will be employed, by whom, and the degree of rigor that will be applied to the execution of those processes to achieve the desired project objective. There are a total of 44 project management processes.

An underlying concept for the interaction among the project management processes is the plan-do-check-act cycle. This cycle is linked by results - the result from one part of the cycle becomes the input to another.

The integrative nature of the Process Groups is more complex than the basic plan-do-check-act cycle. However, the enhanced cycle can be applied to interrelationships within and among the Process Groups. The Planning Process Group corresponds to the “plan” component of the plan-do-check-act cycle. The Executing Process
Group corresponds to the “do” component and the Monitoring and Controlling Process Group corresponds to the “check and act” components. Since management of a project is a finite effort, the Initiating Group starts these cycles and the Closing Process Group ends them. The integrative nature of project management requires the Monitoring and Controlling Process Group interaction with every aspect of the other Process Groups.

The Rational Unified Process

November 2nd, 2008 chris

The Rational Unified Process is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

The Rational Unified Process is a process product. It is developed and maintained by Rational Software and integrated with its suite of software development tools. It is available from Rational Software on CD-ROM or through the Internet.

The Rational Unified Process is also a process framework that can be adapted and extended to suit the needs of an adopting organization.

The Rational Unified Process captures the following best practices in modern software development in a form that is suitable for a wide range of projects and organizations:

  1. Develop software iteratively.
  2. Manage requirements.
  3. Use component-based architectures.
  4. Visually model software.
  5. Continuously verify software quality.
  6. Control changes to software.

The Four Phases of UP

November 2nd, 2008 chris

The following are the four phases of the Unified Process:

  1. Inception - approximate vision, business case, scope, vague estimates.
  2. Elaboration - refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.
  3. Construction - iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
  4. Transition - beta tests, deployment.

UP Practices

November 2nd, 2008 chris

The following are the Practices of the Unified Process:

  1. short timeboxed iterative, evolutionary, and adaptive development
  2. tackle high-risk and high-value issues in early iterations
  3. continuously engage users for evaluation, feedback, and requirements
  4. build a cohesive, core architecture in early iterations
  5. continuously verify quality; test early, often, and realistically
  6. apply use cases where appropriate
  7. do some visual modeling (with the UML)
  8. carefully manage requirements
  9. practice change request and configuration management

Agile UP

November 2nd, 2008 chris

The UP was not meant by its creators to be heavy or un-agile, although its large optional set of activities and artifacts have understandably led some to that impression. Rather, it was meant to be adopted and applied in the spirit of adaptability and lightness, an agile UP.

Some examples of how this applies:

  • Prefer a small set of UP activities and artifacts. Some projects will benefit more than others, but, in general, keep it simple. Remember that all UP artifacts are optional, and avoid creating them unless they add value. Focus on early programming, not early documenting.
  • Since the UP is iterative and evolutionary, requirements and designs are not completed before implementation. They adaptively emerge through a series of iterations, based on feedback.
  • Apply the UML with agile modeling practices.
  • There isn’t a detailed plan for the entire project. There is a high-level plan (called the Phase Plan) that estimates the project end date and other major milestones, but it does not detail the fine-grained steps to those milestones. A detailed plan (called the Iteration Plan) only plans with greater detail one iteration in advance. Detailed planning is done adaptively from iteration to iteration.

The Agile Principles

November 2nd, 2008 chris

The following are the Agile Principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development.
  9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  10. Continuous attention to technical excellence and good design enhances agility.
  11. Simplicity, the art of maximizing the amount of work not done is essential.
  12. The best architectures, requirements, and designs emerge from self-organizing teams.
  13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Agile Manifesto

November 2nd, 2008 chris

The following are the Agile Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Agile Methods and Attitudes

November 2nd, 2008 chris

Agile development methods usually apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and include other values and practices that encourage agilityrapid and flexible response to change.

It is not possible to exactly define agile methods, as specific practices vary widely. However, short timeboxed iterations with evolutionary refinement of plans, requirements, and design is a basic practice the methods share. In addition, they promote practices and principles that reflect an agile sensibility of simplicity, lightness, communication, self-organizing teams, and more.

Example practices from the Scrum agile method include a common project workroom and self-organizing teams that coordinate through a daily stand-up meeting with four special questions each member answers. Example practices from the Extreme Programming (XP) method include programming in pairs and test-driven development.

Any iterative method, including the UP, can be applied in an agile spirit. And the UP itself is flexible, encouraging a “whatever works” attitude to include practices from Scrum, XP, and other methods.