Project Portfolio Management (PPM)

Project Portfolio Management (PPM)

Project Portfolio Management (PPM) is based on the premise that a company cannot undertake each and every project idea that comes about (usually due to limited resources or limited funds). Instead, they must evaluate all project ideas and only move ahead with those that they can staff and fund, and will return the greatest value. Not all organizations use PPM nor do all organizations follow the same process when using PPM. Each organization tailors their PPM process to best meet their business needs. In general, PPM is responsible to "identify, select, finance, monitor, and maintain the appropriate mix of projects and initiatives necessary to achieve organizational goals and objectives."

A portfolio is comprised of "projects, programs, subportfolios, and operations managed as a group to achieve strategic objectives." * The following illustration from the Project Management Institute provides a visual as to both the integration and complexity of a portfolio and its components (subportfolios, programs, and projects). The directional arrows indicate the inter-dependencies between portfolio components. All portions of the portfolio are driven by the strategies and priorities of the organization.

Portfolio, Program, and Project Management Interactions (Figure 1-2)

 

 

FRAMEWORK PROCESS

Below is the flowchart we referenced in the previous video.

Portfolio Management and a Common Product Development Stage Gate Process (Figure 14-15)

 

Documenting and Tracking the Portfolio

Once a portfolio is selected that aligns to the business plan, an integrated view of the portfolio can be documented using various formats. We have two examples to share with you.

In the first example below, the illustration shows how a portfolio can be captured by business area as well as by the timeline as to when the projects and programs will be delivered. You will also notice that each is aligned to the TO BE Vision that is established in the business plan.

Integrated View of Overall Portfolio Strategy (Figure 4-4)

 

In the following illustration, we see another example of how the selected portfolio is documented and tracked. In this example, we see more details around the elements of the portfolio including a more detailed timeline, a list of the completed elements of the portfolio, as well as affected business area operations. This type of format can also be used to support the governance process which will be discussed further in week 3 of our course.

Portfolio Roadmap (Figure 4-9)

 

Project Portfolio Management Challenges

Although PPM sounds fairly straightforward to implement, there are many challenges that organizations face when implementing it. It does require a mature Project Management organization to implement PPM without interference, political overtures, and conflict.

Executives and senior managers must fully support the activity and not launch their own project initiatives outside of the PPM process in order to provide personal or professional gain of their own. Independently launched projects outside of the PPM process can quickly derail the entire organization by not being able to provide the proper financing and resources to deliver on the most critical business initiatives.

Another challenge is that the PPM process relies on the accuracy of the cost / benefit analysis that is done regarding the project idea. If the analysis is not accurate, is incomplete, or worse yet, is intentionally manipulated to look good, then this can cause an organization to select the wrong projects for their focus and attention. This is why a standard process for analysis, along with subject matter expert objective reviews should be conducted on project idea analysis and project feasibility studies. Project and Program Managers should be engaged in this process to ensure completeness and accuracy in the analysis.

Another challenge is that in immature project organizations, there can be a lot of political infighting, causing some executives or senior managers to manipulate other managers within the organization. This political power and influence can sway a project decision to their favor even if it isn't the best project decision for the business.

The final challenge that many organizations face with PPM is being responsive enough to the changing business needs of the organization. PPM must be efficient enough to determine, at any time, if the current portfolio is meeting the needs of the business and to be able to adjust the portfolio quickly if business needs dictate, without complete disruption to the workforce. This can be a challenge in a very dynamic business environment. If an organization relies heavily on a dynamic environment, then the use of Agile projects may be the best approach to the portfolio, as these projects are much more adaptable than Predictive projects. The portfolio could also contain a mixture of Agile and Predictive projects with the more dynamic portions of the business being managed with Agile Project Management.

 

 

Organizational Project Management (OPM)

Organizational Project Management

Organizations that excel in Project Management recognize that they must get the most out of every dollar spent on a project in terms of benefits for the business and for the Stakeholders. In order to do that, a framework called Organizational Project Management (OPM) is used to carefully invest in and monitor the projects with the greatest possible benefit and value. According to the Project Management Institute, "Organizational Project Management (OPM) is a strategy execution framework that utilizes portfolio, program, and project management as well as organizational-enabling practices to consistently and predictably deliver organizational strategy to produce better performance, better results, and a sustainable competitive advantage."

OPM works from the premise that an organization has limitations on budget, time, and resources to deliver their business plan, goals, and objectives. As such, organizations can review projects one at a time and decide if they are worthy to proceed, or they can use an OPM Framework to manage the selection and implementation of a combination of projects for the organization. This review process will ensure the maximum return on investment and that the resources in the organization are not overloaded with work, thereby causing delays in the project and achievement of business results. Organizations that use an OPM framework are also typically at the highest 2 levels of Project Management Maturity.

Organizational Project Management (OPM) Framework

 

OPM FRAMEWORK TRIANGLE

Below is the Organizational Project Management (OPM) Framework triangle we reference in the previous video.

 

 

Comparing OPM Framework Layers

The following table from the Project Management Institute shows a comparative view of each of the layers in the OPM Framework. It provides a summary of how each layer operates as well as how each layer is integrated with the other layers in the Framework.

Comparative Overview of Portfolio, Program, and Project Management (Table 1-1) *

	Projects	Programs	Portfolios
Scope	Projects have defined objectives. Scope is progressively elaborated throughout the project life cycle.	Programs have a larger scope and provide more significant benefits.	Portfolios have an organizational scope that changes with the strategic objectives of the organization.
Change	Project Managers expect change and implement processes to keep change managed and controlled.	Program Managers expect change from both inside and outside the program and are prepared to manage it.	Portfolio Managers continuously monitor changes in the broader internal and external environment.
Planning	Project Managers progressively elaborate high-level information into detailed plans throughout the project life cycle.	Program Managers develop the overall program plan and create high-level plans to guide detailed planning at the component level.	Portfolio Managers create and maintain necessary processes and communication relative to the aggregate portfolio.
Management	Project Managers manage the project team to meet the project objectives.	Program Managers manage the program staff and the Project Managers; they provide vision and overall leadership.	Portfolio Managers may manage or coordinate Portfolio Management staff, or program and project staff that may have reporting responsibilities into the aggregate portfolio.
Success	Success is measured by product and project quality, timeliness, budget compliance, and degree of customer satisfaction.	Success is measured by the degree to which the program satisfies the needs and benefits for which it was undertaken.	Success is measured in terms of the aggregate investment performance and benefit realization of the portfolio.
Monitoring	Project Managers monitor and control the work of producing the products, services, or results that the project was undertaken to produce.	Program Managers monitor the progress of program components to ensure the overall goals, schedules, budget, and benefits of the program will be met.	Portfolio Managers monitor strategic changes and aggregate resource allocation, performance results, and risk of the portfolio.

 

OPM Benefits

Organizations that implement OPM are able to reap many benefits by aligning the business strategy to the execution of the organizational portfolio that supports it. The illustration below shows the benefits achieved by establishing an OPM culture.

Potential OPM Benefits for Organizations (Figure 1-3)

Project Management Institute. Implementing Organizational Project Management: A Practice Guide. (Newtown Square, PA: Project Management Institute, Inc., 2014), 4. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

 

To summarize the image, the following are the benefits of OPM:

• Efficient decision making
• Improved communications
• Predictable delivery performance
• Improved market competitiveness
• Improved cost control
• Effective operations
• Competitive advantage
• Increased productivity
• Alignment of strategy and execution
• Increased customer satisfaction

 

 

Critical Chain Project Management

Critical Chain Project Management (CCPM)

CCPM is used when projects have schedule and resource constraints that must be effectively managed in order to meet project goals. It is a variation of the Critical Path Method (CPM) used in Predictive Project Management. CCPM was created out of a need to get more projects completed more quickly while working within a constrained pool of resources. Just like Agile methods, CCPM requires a maturity level within the organization based on Predictive Project Management methods in order for it to be successful. The basis of CCPM to deliver projects more quickly is to overcome the following phenomenon:

• Parkinson's Law: Work expands to fill the available time.
• Student Syndrome: People start to work to their fullest only when a deadline is near.
• Multitasking: Multitasking can delay the start of the successor tasks and makes us less efficient.
• Common cause variation: There is normal variation that occurs in estimates and probability of completing a task early, on time, or late.

The CCPM method begins with the same Predictive Project Management method used to determine the Critical Path. The project does need a clearly defined goal and objective, as well as a detailed list of activities to be completed in order to produce the expected result. During the Planning Phase when the schedule is to be built, instead of using the Critical Path Method (CPM), the Project Manager would use the Critical Chain Method.

SCHEDULING IN THE CRITICAL CHAIN METHOD

The Critical Chain Method utilizes techniques to prepare a resource-constrained project schedule with the most optimistic schedule dates. In order to do this, CCPM takes advantage of the probabilities of the successful completion of activity durations, removes built-in estimate safety, and adds duration buffers that are non-work scheduled activities to manage risk.

Managing Buffers in CCPM

With a Critical Chain project schedule, the Project Manager is concerned about the starting time of a sequence of activities and the duration of the sequence of activities. To do this, the Critical Chain Project Manager manages the buffers (as opposed to managing individual activities in the Critical Path as in Predictive Project Management). In managing the buffers, the Critical Chain Project Manager protects the actual duration sequence and hence the completion time of the project.

The following chart shows how the buffer management is done:

	1st Third Buffer Penetration	2nd Third Buffer Penetration	Final Third Buffer Penetration
1st Third Activity Sequence Penetration	NO ACTION	Serious problem; immediate action	Very serious problem; aggressive action
2nd Third Activity Sequence Penetration	NO ACTION	Define the problem and formulate a solution	Serious problem; implement the solution
Final Third Activity Sequence Penetration	Task sequence will be ahead of schedule	NO ACTION	Monitor the situation for any further action

In this chart, you are comparing the percentage of work completion in an activity sequence (Activity Sequence Penetration) with the consumption of the buffer at the end of that sequence (Buffer Penetration). Once a sequence of activities is started, as long as those activities are completed within the allowable duration, no buffer time is used. For example, 1/3 of the work in the activity sequence is complete and you've consumed 1/3 of your buffer, then no action is needed at that point, other than to continue to monitor the amount of work completed compared to the amount of buffer consumed. If an activity is completed early, the time can be added to the buffer. If an activity in the sequence is completed late, then this consumes some of the buffer time. The Project Manager monitors this buffer consumption and as long as it is in line with the completion percentage of the project, then little action is needed.

When you need to begin taking action is if you are consuming your buffer at a higher rate of speed than you are completing the work in the activity sequence. That implies that you will run out of buffer, which also means your project will be delivered late and probably also over budget. For example, if you've completed only 1/3 of the work in the activity sequence (Activity Sequence Penetration) but you've consumed 2/3 of your buffer, that means you only have 1/3 of your buffer left to cover any late delivery of 2/3 of your work. That is out of balance and would require significant action, likely an approval to add more buffer and more budget. In this way, the Critical Chain Project Manager is more concerned with managing the duration of a sequence of activities and buffer penetration rather than being concerned about each individual activity completing on time.

Implementing CCPM

Implementing Critical Chain Project Management requires a high level of Project Management Maturity within an organization as well as preparation, training, and a mindset shift from Predictive Project Management. Organizations that implement CCPM can not be concerned about measuring such things as employee utilization (measurement of how busy employees are) as the focus for the project work is how fast the activities can be completed with quality results. Resources can't be distracted with other work activities, or otherwise slow themselves down from achieving the aggressive duration estimates in the Critical Chain.

"The best analogy to use to explain the different mindset associated with CCPM is to think about how a Relay Race is run. How does a Relay Runner act? At the start of the race, the first runners arrive early, prepare, and wait for the start. As soon as the race starts, they run as fast as possible. The next runners in the relay are ready and waiting. They are not asked to "make good use of their time" or to "increase their utilization" by working on something else while they are waiting. They wait, so they are able to start running as soon as they get the relay baton. And then all they do is run their leg of the race without being distracted by other activities."

 

What is Scrum? What are the roles in Scrum?

Scrum (Agile Process)

Scrum is one of the most popular Agile Project Management Methods. Scrum is an agile process that allows the project to focus on delivering the highest business value in the shortest time. It is designed to work in iterations so that every 30 days (or so) there is a working product created. The business sets the priorities of what is developed in each iteration. The Agile project team is self-organized to determine the best way to deliver the highest priority features. This requires extremely close collaboration amongst an experienced group of professionals.

Learning how to manage a project using an Agile method such as Scrum requires training and additional knowledge. It also requires a change in organizational culture and an acknowledgement by management that to support Agile projects requires a different focus than Predictive projects.

ROLES IN THE SCRUM PROCESS

In Agile, there isn't really a Project Manager that manages the entire process. The Scrum process has primarily 3 roles: The Product Owner, the Scrum Master, and the Team. The role of the Project Manager is spread across each of the three Scrum roles. There are also clients and other Stakeholders that may be engaged in terms of the users of the product being produced or the providers of product features and requirements.

The Product Owner is responsible for:

• Understanding the client's requirements and business needs
• Defining the features of the product
• Prioritizing features according to market value or business need
• Adjusting features and priority every iteration, as needed
• Accepting or rejecting work results

The Product Owner has significant business knowledge, or otherwise, they would be unable to make these types of decisions. They also must have very close relationships with the project clients and other Stakeholders.

The Scrum Master is specially trained and is responsible for:

• The correct and effective use of Scrum practices
• Removing barriers for the team
• Ensuring that the team is fully functional and productive
• Enabling close cooperation across all roles and functions
• Shielding the team from external interferences

You will notice that many of these responsibilities seem similar to the traditional definition of a Project Manager role. However, this role has specialized training to be able to apply the Scrum method to an Agile project.

The Team is typically small - between 5 and 10 people. The team normally has full time dedicated staff with the skills necessary to create the product. The team usually has cross functional skills required to produce a product such as programmers, designers, testers, etc. whatever is required to build a functioning product. The team is highly experienced and mature in their ability to manage their own time, to be innovative and to adjust the work as required to deliver the functions agreed to in the Sprint. They self direct their work based on the features selected for the the Sprint without someone assigning specific tasks to them.

What are different Project Management Methodologies and Methods used in Agile?

What Different Project Management Maturity Levels Look Like

So what do these maturity levels look like in an organization? In the following table, we will cover what support, training, Project Managers, and Project Management standards look like for each level of maturity.

	Embryonic	Executive Management Acceptance	Line Management Acceptance	Growth	Maturity
Support	Recognize a need for Project Management but little to no active visible support from executives or line managers.	Executives understand and support Project Management, but not all line managers actively support Project Management.	Executives and all line managers understand and support Project Management.	All employees understand and support Project Management	Projects are integrated into the business plan and business success.
Training	Little to no training for Project Managers or other employees.	Some training for Project Managers, executives and/or managers.	All employees are trained on Project Management concepts and roles.	All employees are trained on Project Management standards used and roles. Advanced level training for Project Managers.	All employees are trained on Project Management best practices, standards and roles. Project Managers have clear career path for professional growth.
Project Managers	Very few Project Managers or functional leaders act as Project Managers.	Project Managers assigned to some projects but may not be full time.	Full time Project Managers are assigned to most projects.	Full time Project Managers are assigned to projects.	Full time Project Managers are assigned to projects.
Project Management Standards	No standards. Project success occurs based on the skill of the Project Manager as opposed to the support of the management or organization.	No standards. Some methods may be used or being identified for use.	Project management method used but non-standard or inconsistent.	Broad use of a standard Project Management method. Investment in maturing Project Management standards.	Best in class Project Management methods supported by best practices. Integrated business and project tools.

 

Project Management Methodologies

Organizations that reach the Growth and Maturity phases in the Maturity Model have invested time, money, and resources in the development of a standard methodology, thus achieving maturity in Project Management practices. A methodology is a series of processes, activities, and tools that are part of a specific discipline (such as Project Management) and designed to accomplish a specific objective. Methodologies can include a set of forms, guidelines, templates, and checklists that can be applied to a specific project. For companies that understand the importance of a standard methodology, the benefits are numerous: *

• Faster time to market
• Lower overall program risk
• Emphasis on customer satisfaction and value-added

There are multiple types of methodologies that can be used for projects. For organizations in the Growth and Maturity phases, they must have methodologies that meet the needs of their business, employees, and clients. We explore the Predictive method of managing projects (sometimes referred to as the Traditional method). This approach is widely accepted in the Project Management industry, but it is not the only method available.

Predictive Project Management, Agile Project Management (APM), and Critical Chain Project Management (CCPM) are three methods we will explore, compare, and contrast for greater understanding as to when each method should or could be used to optimize project success. The key is to match the needs of the project, the business, and the client to the correct method for the best results.

Predictive Project Management:
Predictive Project Management is used when the solution is clear and the goal is clear. This largely has to do with how Predictive Project Management works. Predictive Project Management is based on a life cycle of processes, from initiation through closure.

The process starts by identifying the expected result of the project, the objectives and goals that the project must meet, and the definition of the scope of the work of the project in order to create that result. 

This approach can only be used if the resulting product or service and goal are clear. Otherwise, we would not be able to detail out the project scope and the project plan. Without a detailed project scope, Predictive Project Management cannot be carried out correctly.

Once the detailed plan is developed, all the work as documented in the plan is completed in order to deliver the results of the project. Once all the work is complete and the deliverables are produced, the project is closed. This process works for projects with clearly-defined goals and results. However, when this process is forced on projects without clearly-defined goals or results, then problems can ensue, causing significant changes or missed expectations.

Agile Project Management (APM)

Agile Project Management is used when the goal of the project is clear, but the resulting product is not clear or only partially clear. In this scenario, the use of Predictive Project Management becomes difficult in that the details of the project scope and deliverables can not be fully documented. In this case, a different method should be used in order to effectively deliver the project. These projects are best delivered through the Agile Project Management method, which is adaptive in nature because the project goes through a series of iterations. This method is more amenable to accepting changes to the resulting product throughout the project. Because of its adaptive style, Agile Project Management has significantly grown in popularity and use in the last decade. According to the Project Management Institute, the use of Agile has tripled in the past 8 years. There are also studies from The Standish Group that indicate the success rate of Agile Project Management exceeds those using Predictive Project Management methods by as much as threefold. Agile originally was developed to better manage software projects, therefore much of the available literature and information is focused on software development. However, the Agile methodology has been adopted now by multiple industries.

Agile Method Types

The term "Agile" is more a description of a type of method. Within the Agile arena, there are multiple specific methods that have been developed. Scrum is one of the most well known Agile methods.

The Scrum Process Flow (Figure 12-14)

Wysocki, Robert K. Effective Project Management: Traditional, Agile, Extreme. 7th ed. (Indianapolis, IN: John Wiley & Sons., Inc., 2014).

The term Scrum comes from the sport of rugby. Think of how a rugby team plays - they all work together moving the ball down the field toward the goal, but the direction, approach, and results may be different each time. The Scrum method for Agile works similarly. A strong cohesive team with daily interaction with the client is required. The solution is developed in Sprint iterations, with each Sprint having a defined set of functions to deliver within 30 days. A product is developed at the end of each Sprint and reviewed with the customer. After each Sprint, the final product becomes more and more developed.

Scrum is not the only Agile method. There are other Agile methods such as Extreme Programming (XP), Dynamic Systems Development Method (DSDM), and Lean Development. All of these methods follow the same basic principles as previously described. Both XP and DSDM are mainly software development Agile methods. Lean Development incorporates the concepts of Lean Manufacturing in its approach and similar to Scrum, it can be used on various types of projects, although both of these methods are still primarily used in software development work.

Limitations to Agile

You might be thinking, why doesn't every project use Agile? There are some limitations and risks associated with Agile that must be considered before it is selected for use on a project. Agile does not satisfy top management's need for budget, scope, and schedule control.

• If the organization's management or the customer for the project requires a contract in advance that articulates what will be delivered for the solution, when it will be delivered, how it will perform, and exactly what it will cost, then Agile is likely not the best method to use. Predictive Project Management would be a better choice in this scenario as Predictive Project Management can provide this level of detail, where Agile Project Management cannot.
• Agile's principles of self-organization and close collaboration can be incompatible with corporate cultures or with client cultures. Agile works well with small, self-directed teams that organize the work on a daily basis and subdivide the work to be accomplished across the team, while being in regular daily communications with clients. Some organizations or clients may not be able to effectively support this highly collaborative model as it relies on a significant level of trust, communication, and teamwork to work effectively and a clear dedication of time and attention.

Think back to our discussion around the Project Management Maturity phases from earlier in this lesson. Typically, organizations that use Agile methods are at the Maturity phase within the model. Organizations that have little to no acceptance, understanding, and commitment to Project Management methods that venture into the Agile space may find it more difficult to succeed than if they first begin by understanding Predictive Project Management and then move the appropriate projects to an Agile method as their experience and expertise grows.

 

Key Factors for Project Success and Failure.

 

Key Factors for Project Success

• Executive sponsorship
• Maturity of Project Management practices
  
• Alignment of projects to strategy
• Value of Project Management is understood
• Project Manager skill development
• Project Management Office
  

 

 Contributing Factors to Project Failure

Now that we have looked at some of the success factors for projects, let's examine some of the key reasons why projects fail.

1. Poor Executive and Management Support
   Project Managers are not the only ones who need to support a project for it to be successful. Every executive and manager needs to understand the importance of Project Management, the role projects play in achieving business goals and provide active support for their success.
2. Poor Planning
   Project Managers and project teams need to understand the goals and objectives for the project and the value and benefits it is expected to achieve. The project plans must be built to support the achievement of the goals, objectives, and benefits.
3. Poor Monitoring and Control
   Having proper project metrics, and monitoring and control mechanisms on a project are key to ensuring the project is meeting the plan. It is important to properly use the project plan to control the outcome and meet Stakeholder expectations. If the project manager can't trust the plan will lead the team to success, then the plan was not built correctly.
4. Poor Leadership Skills
   Understanding project management methods is important for a Project Manager, but it isn't what creates great project managers. Great project managers are set apart from their average counterparts because of their leadership skills.
5. Poor Resource Management
   Project Managers must be very adept at identifying all necessary and skilled resources (human and non-human) needed to be successful. The right resources available at the right time is a critical element to successfully achieving project goals.
6. Accidental Project Managers
   Sometimes even with the best of intentions, organizations may assign Project Managers that don't have the appropriate experience or skill to be successful. They may have been successful on a small project and believe that success can translate to a larger more complex project with ease, only to find out after the project fails that this wasn't the case. Project Managers need the proper skills that grow with the complexities and challenges of the projects they manage.
7. Poor Communication
   When communication flows freely up the organization, down the organization and across the organization, then projects can be effectively delivered and issues can be addressed quickly. When communication is hindered, bad information or lack of information can send a project off in the wrong direction.
8. Unsupportive Organizational Culture
   The culture of an organization establishes its priorities and effectiveness. When the culture conflicts with the project goals or does not support the necessary project elements for success, then projects (and Project Managers) will struggle to achieve success.
9. Too Many Projects - Too Few Resources
   When organizations don't prioritize and systematically select the projects that will lead to the greatest value, then resources are over allocated and little progress is made on anything. Projects need to be viewed as part of a portfolio of work and must be balanced with the resources available to achieve business and Stakeholder value.
10. Not Properly Managing the Tradeoffs
    Projects by their nature have competing constraints most notably: time, cost, and scope. Additionally, Project Managers must manage the expectations and relationships of Stakeholders and ensure customer/business value is delivered. Managing these competing constraints requires making the right tradeoff decisions and setting the right priorities for each individual project they manage. Recognizing when these decisions need to be made in the best interest of the project, the project team, the company, and the Stakeholders is key to being successful.

 

 Comparing Factors for Success and Failure

Looking at the comparison of the elements of a project that are needed to be successful and the elements of a project that are known to cause project failures, we can see some similarities.

Needed for Success	Can Cause Failure
Executive support	Poor executive and management support Poor communication
Maturity of practices Project Management Office	Poor planning Poor monitoring and control Poor resource management
Alignment to strategy	Unsupportive organizational culture Too many projects - too few resources
Demonstrate value	No quality at the source, no planning for rework
Skill development	Poor leadership skills

As we examine various case scenarios in this course, remember these elements and how they might have applied to the troubles that some companies find themselves in.

In order to achieve high performance, the Project Manager needs to be able to master all of these elements. For example, this means the Project Manager needs to ensure they have effective sponsorship for their project, that they are utilizing mature practices and methods, that they engage the right people at the right time on the right job, and that they enable value for the business. Throughout this course we will review how to avoid the elements that cause project failure to provide the best possible environment for project success.

 

 

Triple Contraints in Project Management

Understanding who uses Agile also requires understanding the methods employed to control a project's constraints. This brings us back to the Iron Triangle for the Triple Cost Constraint:

• Scope - controlling the work done
• Schedule - controlling the calendar time for doing the work
• Budget - controlling capital expenditures

Controlling Scope

• Traditional
• Work Breakdown Structure (WBS) - controls work by concretely defining its components
• Often has three levels: Product, Major Features, Feature Components
• Used to define what will and will not be in a project
• Change Control Board (CCB) - controls changes to the WBS by committee review
• Includes all major stakeholders
• Must be organized and often slows changes to a project
• Lean
• Tickets - identify work items and their priority for response (urgency and impact)
• Requests -  these are informal or semi-formal requests that could be tickets
• Notes
• Both tickets and requests go into a queue for work, and are executed through a value stream
• Value streams are steps to complete work (e.g. define, analyze, build, test).
• Agile
• Product Backlogs - the list of work to be done for the entire project. It's an ordered list of work increments.
• Sprint Backlog - the work that will get done during the sprint.

Note that Backlogs are used for Tickets in Lean and Stories in Agile. You can also have what's often called the "Kanban Sandwich" where Lean processes are used to set Sprint Goals, Agile is used to manage a Product and Sprint Backlog, and then work during a sprint is managed in a Lean process.

Controlling Schedule

• Traditional
• Estimated Tasks and Schedules - work is estimated and modeled for precedence
• Program Evaluation and Review Technique (PERT) - adds stochastic modeling of task completion
• Critical Path Method (CPM) - uses deterministic modeling to identify critical tasks for on-time delivery
• Notes
• Determining the critical series of tasks helps to focus managers in traditional on the important tasks
• This does not necessarily align with business importance
• Schedule and scope are fixed, however, scope modeling comes before scheduling to define estimates and dependencies in the work
• A schedule is considered the primary tool in Traditional Management for controlling delivery
• Lean
• Kanban & Queues - work is managed in a list and executed based on priority
• Service Agreements - sets the priority of work by defining what is critical, major, or minor
• Notes
• Together the Kanban & Queue techniques, along with the Service Agreements, allow for Lean projects to adjust when delivery will occur for each work item.
• This is intended since schedule is varied in Lean projects
• Agile
• Timeboxes - a set period of time in which the most important work is done first
• Releases and Roadmaps - sets goals for major features to be release together
• Notes
• Timeboxes are used at all levels of the project to set deadlines
• Sprints are given a fixed time to drive improvement
• Any work not done in the timebox goes back into the backlogs
• Releases and Roadmaps set objects for multiple sprints that can be met at varying quality levels
• This allows for the most important work to achieve an objective to get done first
• This aligns the business importance with what work actually gets done on time

 

Controlling Budget

• Traditional
• Earned Value Management (EVM) - compares current performance to the plan
• Planned Value (PV) - shows the cost over time expected to complete the work on schedule
• Earned Value (EV) - shows how much work is completed to date
• Actual Cost (AC) - shows the cost so far to complete the work
• Cost Centers
• Evaluates the differences in performance by cost center
• Cost Performance Index (CPI) is the factor EV / AC, where above 1.0 means good performance
• Schedule Performance Index (SPI) is the factor (EV / PV), where above 1.0 means good performance
• This allows you to estimate the costs or savings expected for on-time delivery of total scope
• Lean
• Service and Severity Levels - sets the level at which the company reaps benefits from the solutions
• Service Levels set the Goal
• Severity Levels set the Impact of meeting or not the goal for different problem types
• Key Performance Indicators (KPIs) - evaluate performance against goals for set time periods
• If the KPI is meeting or exceeding the Service Level Goal, then you're making money
• KPIs will often vary over time, so it's important to look at trending
• Agile
• Return on Investment (ROI) - the net income as a ratio to total investment
• Positive ROIs should be expected after the first or second release of a product
• Allows for selecting and refining the backlogs
• Burndown Charts - shows progress in achieving the backlog over time
• Used for projects that haven't yet released the project, or cannot easily estimate ROI
• Projects often start with a set of stories and story points estimated
• The expectation is a linear burndown - meaning a linear decrease in total remaining work to be done
• Teams often are slow at the beginning and speed up over time, or hit snags that stall backlog burn 

Simple Project Management Methods

 

This lesson is all about understanding the high-level components for each Project Management Method:

• Traditional
• Agile
• Lean

Traditional Project

• Idea - Traditional projects start with an Idea by the owner or team
• Business cases - Business Cases are performed for each concept; often a qualitative and quantitative process
• Bid & Proposal - Project scopes of work are written and competed amongst teams
• External vendors will submit bids and proposals to win work against a Request for Proposals
• Internal teams will submit budgets and proposals to win allocated funding from a PMO or Portfolio function
• Waterfall Development - each stage is executed sequentially, with limited iteration or "going backward" in stages
• Requirements - the process of defining high, medium, and low-level needs of the end users and stakeholders
• Design - the process of architecting the solution to meet those requirements within the project contraints
• Implementation - the building of the product to specification
• Verification - the testing and product to ensure it meets specifications and the requirements' intent
• Maintenance - the design of and support of deploying and maintaining the product in operations
• Operations - the use of the product to produce benefits to the organization
• Disposal - the retirement of the project according to regulations and sustainability practices

Often the Traditional Process is controlled further with Stage Gates, where stakeholders agree the project is ready to move from one Waterfall Development Stage to the next. This can help give executives clear points of approving or disapproving the work; as well as inform stakeholders of the high-level progress of development.

Standard Stage Gates:

Idea Readiness Review (IRR)	precedes Business Cases
Concept Readiness Review (CRR)	precedes Bid & Proposal Stages
Planning Readiness Review (PRR)	precedes Requirements phase
Requirements Readiness Review (RRR)	precedes Design phase, exits Requirements phase
Design Readiness Review (DRR)	precedes Implementation phase, exits Design phase
Implementation Readiness Review (IRR)	precedes Verification phase, exits Implementation phase
Operational Readiness Review (ORR)	precedes Maintenance (O&M) phase, exits Verification phase
Operations and Maintenance Review (OMR)	Precedes Disposal phase, exits Operations (O&M)

 

Agile Project Management

• Idea - (see Traditional above, it's the same)
• Business Case - (see Traditional above, it's the same)
• Bid & Proposal - (see Traditional above, it's the same mostly, except the contract type may differ)
• Early Agile Development (Pre-Release of first version)
• Sprints - use the Scrum Method to deliver increments of working product iteratively until release ready
• Sprint Planning - Product Owner and Team plan work for the sprint
• Sprint Development - Team designs, builds, and tests increments of work in a fixed time period
• Sprint Retro & Review - Customer reviews the work and team reviews the sprint for improvement
• Deploy First Version to Production - this first version is often called the minimum viable product (MVP)
• Continuous Delivery (Post-Release of first version)
• The same team(s) supports development and operations or "DevOps"
• These are still executed using the Sprint model, only the team must account for supporting Operations
• Development
• Create - try something new or build fixes
• Verify - ensure that it works
• Package - get it ready for release
• Operations
• Release - deploy the new features/enhancements/bug fixes
• Configure - ensure operations and test features on/off
• Monitor - monitor performance of functionality
• Plan - prioritize the next improvement or fix
• Disposal - (see Traditional above, it's the same)

 

Lean Project Management

• Issue - could be an idea, major problem, or series of problems the client or owner foresees for the business
• Work Concept - work is formed as either a series of small challenges or one big challenge
• Issue Backlog - for support contracts, there needs to be total or sample backlog of work to support
• Technical Challenge - for technical solutions, there is a challenge set with clear performance objectives
• Bid & Proposal - (see Traditional above, it's the same; although contract types will differ)
• Work Definition
• Dispose Issues - issues are classified in urgency and impact to define the priority and who should respond
• Define Work Breakdown - team evaluates and decomposes the Technical Challenge into a work breakdown structure or "WBS."
• Continuous Delivery
• Value streams - support for solving lots of small problems goes through a series of predefined steps to ensure quality and drive customer satisfaction the issue is addressed.
• This is often supported using a defined workflow
• The issues are routed based on priority and impact to different team members
• Only the client or customer or their representative can accept it as done
• Incremental Delivery - a team will incrementally work through the WBS to solve a major problem
• Often use a Kanban board to solve highest priority/most uncertain work
• Delivery is continuous and incremental to explore solution sets that COULD work
• Operations - solutions are deployed into operations where customers receive benefits
• Example issue solution - solving someone being locked out of their system
• Example Technical Challenge solution - deploying a new upgraded machine for manufacturing a car
• Disposal - (see Traditional above, it's the same)
  

Evolution of Agile Project Management

 Evolution of Agile

TQM: The story of Agile as we know it today begins with Total Quality Management or "TQM," developed by Edward Deming. This was also the origin of the Lean movement that pushed for continuous improvement and appreciation of workers. The core tenants of TQM include:

• Improving Quality Decreases Costs - lowers costly defects, customer support, and recalls
• Continuous Improvement - for the systems and people in the systems
• Pride of Workmanship - the primary driver of knowledge workers and source of quality is joy in good work
• Plan-Do-Check-Act  (PDCA) - this cycle allows for testing a complex system that can't be modeled easily

 

One of the famous beliefs was that the Knowledge Worker is different from the Manual Laborer, because the Knowledge Worker knows more about the work than their boss does.

 

Proof that TQM Works: Edward Deming turned around Ford Motor Company in 1986 from billions of dollars in losses to its first profits in years using the TQM approach.

 

TPS: The Toyota Production System (TPS) was developed by Taichii Ohno that was the first true Lean system. Focus was on reducing waste, based on lessons from TQM. The focus was on reducing the wastes in a system:

• Eliminate 7 Wastes - Movement, Inventory, Motion, Waiting, Overproduction, Over-Processing, Defects
• Small Batches - exposes errors and minimizes waste in the system, by using a "Pull System" using Kanban
• Kanban - means "billboard" and it is a system to tell upstream processes to send work downstream
• Kanban boards have at least three columns: To-Do, Doing, Done
• Kanban boards limit work-in-progress (WIP) by limiting the number of items in the "Doing" column and only pulling in more work once the current work in progress is done
• Continuous Improvement with Key Performance Indicators (KPIs)

 

Proof that TPS Works: Toyota is a top three (3) manufacturer of cars, with a 70% employee satisfaction rating - that's more than double the satisfaction rating of employees in the USA, which stands at 30%.

 

TOC: The Theory of Constraints (TOC) was developed by Eli Goldratt. It emphasizes that the system is always governed by a bottleneck and there is a competition between local optimization and system (global) optimization. The theory states that Throughput of the system should be the focus of managers, not "Cost Centers" that drive local optimization. His ideas are captured in the famous book The Goal which is read widely and cited as critical to the revolution of management in the 1980s.

• Throughput drives cost and revenue
• Throughput is constrained by one process in any system, the constraint
• To improve the System Throughput one must focus on optimizing around the Constraint
• To do this, use the 5 Focusing Steps for the Process of Ongoing Improvement (POOGI)
1. Identify the Constraint - figure out which process is limiting
2. Exploit the Constraint - try to optimize with existing capacity
3. Subordinate everything to the Constraint - reduce processes to match capacity of the constraint
4. Elevate the Constraint - add capacity to the constraint process
5. Prevent inertia from becoming the Constraint - be vigilant and check if there's a new constraint!

 

Proof that TOC Works: TOC was used by the BP Oil Spill Cleanup initiative to save over $200M and rapidly deploy 10,000 boats after the Gulf Oil Spill to skim and clean oil from the surface.

 

The Waterfall Mistake

• Waterfall was never intended to be linear in its design
• Royce, who proposed waterfall as a simple starting point for modeling work, stated all projects should iterate
• Typical waterfall design:
• Requirements - product requirements as output
• Design - architecture as output
• Implementation - system is produced
• Verification - testing is conducted to fix the system where needed
• Maintenance - support for product in use
• The actual design had at least one iteration going back from verification to implementation to design

 

Only 10% of software projects were successful in the 1970s, and using waterfall we still see that half of those projects fail today.

 

By 1980s the Waterfall Method was being used by DoD (and continued until 1996), which resulted in the Ninety-Ninety Rule:

"The first 90 percent of coding accounts for the first 90 percent of development time,
The last 10 percent of coding accounts for the other 90 percent of development time" - Tom Cargill, Bell Labs

 

Important reference: Waterfall Model Probably the Most Costly Mistake in the World:

http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en

 

The original paper from Winston Royce on Waterfall Methodology: 

Winston W. Royce (1970). "Managing the Development of Large Software Systems" in:
Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA

Iterative Methods

• Rapid Application Development (RAD) - popular during 1970s and 1980s
• Upfront requirements
• Iterate on Design and Development
• System Cutover
• Dynamic System Design Methodology (DSDM) - popular in 1980s and 1990s
• Introduced iteration of requirements (foundation)
• Included going back to design and development as well
• Still had a "Feasibility Stage" upfront
• Extreme Programming (XP) - popular from 1990s to 2000s
• Iterative across all levels (Pair programming, unit testing, standups, testing, and planning)
• Required heavy iterations and redundancy in resources to manage risk
• Continues to be used today

 

Key Tenants of Iterative:

• Consolidated Up-Front Planning - RAD and DSDM did not refine, but XP does
• Iterate on Designs - design, build, test, refine
• Timeboxes - to ensure continuous, on-time delivery
• User Stories - to describe requirements (introduced as standards in XP)
• Test-Driven Development (TDD) - enables exploration of designs and refinement before release

 

2013 Cross-industry Study by Ambysoft shows the following (see the details of the survey here http://www.ambysoft.com/surveys/success2013.html):

• Agile is more successful than Traditional
• Agile is less challenged than Traditional
• Agile fails less than half as often as Traditional

Project Measure	Agile	Traditional
Successful	64%	49%
Challenged	28%	33%
Failing	8%	18%

Note: This table is reproduced from the summary graphics of Ambysoft's survey found here: https://clearcode.cc/blog/agile-vs-waterfall-method/

 

Knowledge Check

Question 1

The history of Agile is a total quality revolution. What are the three management revolutions that led to the evolution of Agile?

Waterfall, Spiral, and Iterative

PDCA Cycle, Kanban, and Theory of Constraints

Total Quality Management, Toyota Production System, and Theory of Constraints

Rapid Application Development, Dynamic System Development Methodology, and Extreme Programming

Question 2

According to the lecture, what are the key tenants of Iterative Development (choose 4 of 6)?

Consolidated up-front planning

Iterative development

Frequent documentation

Emphasized on-time delivery

Test-driven development

Emphasized tech specs