Comparing Project Management Methods Across Industries

 

Comparing Methods Across Industries Summary Points

The central part of this lesson is understanding this table below on Size and PM Method:

	Traditional	Agile	Lean
Project Size	Large	Medium	Small
Industries	Construction Military Government / Policy Relocation	Information Technology Product Development Consulting Operations	Sales Customer Support Legal Research & Development
Planning*	Master Schedules	Releases	Backlogs  (Prioritized Lists)
Sourcing	Efficiency	Trust	Expertise
Goals	Predictable  (Low Cost)	Speed  (Maximize ROI)	Innovation  (Problem Solve)

 

Traditional

• Typically Large
• Many connections between stakeholders
• Impact many stakeholders
• Many departments
• Many technologies and concerns
• Good Examples are
• Large building construction
• Military platform acquisition
• Government civil works projects
• Planning is done using a Master Schedule
• Goal is to be predictable and efficient (low cost)

 

Agile

• Typically Medium in size
• Good examples are
• Building new products
• Ex. SpaceX used modular designs to launch many types of rockets
• Ex. Apple Operating Systems with regular releases over time (incrementally better)
• Planning is done in Releases
• Goal is to get out to market
• Each cycle builds on what came before in releases
• Goal is to be fast and make money (maximize return on investment, ROI)

 

Lean

• Typically Small
• Good examples
• Building a new solar panel
• Selling or closing a deal
• How we manage ourselves
• To Do:  Get the dog from the vet
• Doing:  Pick up kids from school
• Done:   Bought the presents for the kids' party
• Planning Uses Value streams and Lists
• Setting up a process (e.g. To-Do, Doing, Done)
• Establishing a backlog of work to go through that process
• Goal is to be responsive and innovate (problem solve)

A key question we should ask after considering is why do these groups form around size? Why are the Traditional projects large? The Agile projects medium in size? The Lean projects small?

Asking these questions drives us to the next lessons on key concerns: Customers and Engineering.

 

Comparing Methods of Customer Management Summary Points

	Traditional	Agile	Lean
Project Size	Large	Medium	Small
Industries	Construction Military Government / Policy Relocation	Information Technology Product Development Management Consulting Operations	Sales Customer Support Legal R&D
Customer Size	>250 participants	Up to 250 participants	Up to 10
Customer Communication	Representatives Large, Facilitated Meetings	Part of the Team Small Meetings	On-Call Ticketing / Request
Payment Method	Firm Fixed Price / Custom Pricing (Quote)	Time & Materials / Retail Purchase (Paid)	Cost-Plus / Subscription (SLA)

 

Traditional

• Customer Size: >250 participants (customers and team)
• Greater than Dunbar's Number
• Many different groups and sets of concerns
• Customer Communication: Formalized
• Large Facilitated Meetings (Public Meetings or Hearings)
• Large Surveys and Teams of Interviews
• Representatives are sent (such as in government) to represent large stakeholder groups
• Change Control Boards ensure all stakeholder (groups) are heard
• Payment Methods
• Almost always Firm-Fixed Price (cannot change the price)
• Requires custom quotes because of the size and complexity
• This involves complex parametric estimation

 

Agile

• Customer Size: Up to 250 participants (customers and team)
• Department user groups
• Clear Market Segments
• Customer Communication
• Customers are on the team
• Customers engage in ceremonies and provide immediate feedback
• No delays, and often just one representative can suffice for decisions
• Sometimes working groups help to coordinate across functional concerns
• Payment Methods
• Time and Materials (T&M) to scale resources for fixed periods of time
• Retail Purchase (Paid), where a fixed price and targeted units sold ensure profits

 

Lean

• Customer Size: 10 people or less (customers and team)
• Single user who needs support
• One product group that needs new technology
• One owner or a small group that needs expert advice
• Customer Communication
• On-Call support (customer calls the vendor)
• Ticketing systems (customer logs an issue)
• Communication is then one-on-one with issue holder
• Payment Methods
• Cost-Plus contracts (guaranteed profit plus any expenses)
• Subscription (SLA) or Fixed Fee

Hopefully these new details are opening up one clear set of constraints on Project Management Methods: The Customer. Scheduling and managing resources using traditional means, with large meetings and formal communication can really make sense at scale; but also when you have many differing concerns in requirements (stakeholder groups), or an unavailable customer on large, complex work. Agile works well when the customer prioritizes your project and there can be a single, decision-making representative. Lean makes sense when the customer needs immediate attention, but at uncertain intervals. Lean also makes sense when the work and complexity is very small (although the expertise level may be very high).

But is it always up to the customer? What about the product? What kind of engineering is required or resultant based on these methods to maximize their potential returns?

Comparing Methods of Engineering Management

Depending on the method of Project Management (PM) selected our goals in Engineering design change. What does that mean for the Project Manager? Everything, if you're being held accountable for successful delivery!

We sometimes see the product as driving PM Method choice, but this is rarely the case. The Customer (s) type, availability, and total number of stakeholders drive the management method. The work must meet those demands, based on the goals set. 

• Traditional must be efficient in design
• Agile must release early and maximize value with iterative releases
• Lean must be responsive and provide services or products based on client priorities

To do this results in very different design paradigms, coupling of services, and resultant architectures. This lesson will explore those together, along with the Engineering Team makeup that also derives from the PM method choice. This forces new design, development, integration, and testing concerns on the creators. 

Can you imagine how the Project Management method would bind or release your creativity? What about getting feedback on your designs? What about acceptance?

Enjoy this lesson as you explore the stark differences each method produces in what's under-the-hood in your final delivery!

Important Note Before You Go:

• In this lesson there will be discussion of Applications, Features, and Services
• These are Systems Engineering Terms, and Common Terms for many problems - beyond Software Engineering!
• Here's how it breaks down:
• Application - the business use of product(s) or service(s) to support the organization
  (e.g. a new car from the dealership) 
• Feature - an aspect of an Application that delivers value to its customers
  (e.g. automatic air conditioning)
• Service  - a set of functions that serve a common purpose 
  (e.g. air sensor system, air cooling system, air heating system, ventilation)

Comparing Methods of Engineering Summary Points

	Traditional	Agile	Lean
Project Size	Large	Medium	Small
Industries	Construction Military Government / Policy Relocation	Information Technology Product Development Management Consulting Operations	Sales Customer Support Legal R&D
Design	Dependent / Coupled	Independent / Decoupled	Constrained / Evolutionary
Teams	Departmental	Matrixed / Projectized	Emergent (Ad Hoc)
Development	Linear	Iterative	Incremental
Integration / Testing	End Phase	Continuous	When Possible
Closing	3rd Party Acceptance	Team Acceptance	Customer Acceptance

Important Note Before  Reading Further:

• In this lesson there will be discussion of Applications, Features, and Services
• These are Systems Engineering Terms, and Common Terms for many problems - beyond Software Engineering!

Here's how it breaks down:

• Application - the business use of product(s) or service(s) to support the organization 
  (e.g. a new car from the dealership) 
• Feature - an aspect of an Application that delivers value to its customers 
  (e.g. automatic air conditioning)
• Service  - a set of functions that serve a common purpose  
  (e.g. air sensor system, air cooling system, air heating system, ventilation)

Traditional

• Designs are Dependent of Coupled  & Development is Linear
• Driven by need for efficiency
• Heavy amounts of reuse across components
• Drives multiple dependencies into the system
• Any small change in the services results in BIG costs
• This can be efficient with few changes
• Teams: Departmental
• To be efficient we use multiple departments or contracts
• This specialization will lower costs of delivery
• These teams are then matrixed into the project
• Integration and Testing: End Phase
• Because of tight coupling, only at the end phase can we really test
• All parts are connected and could impact each other
• This delays feedback, which in turn freezes requirements
• Closing: Third Party Verification
• A third-party tester is needed to match requirements to the final product
• Only this way can multiple stakeholders trust the results
• This is also a large job, requiring verification expertise

Agile

• Designs are De-Coupled & Development is Iterative
• Allows for building features one at a time
• This requires additional scope around supporting services to make features independent
• This reduces costs of changes, but increases baseline costs
• This also allows for early release of features or minimum viable products (MVP)
• Each iterative release can build on the release that came before it
• Teams: Matrixed / Projectized
• Everyone is on the team
• All departments see and hear the same intent
• This ensures maximum accuracy in communication
• The customer is also on the team
• This also enables speed, reducing handoffs and delayed decisions
• Integration and Testing: Continuous
• By continuously testing the work, the work can be closed for each release
• This is done on cadence with the owners
• This ensures that new features don't break old ones as we add scope with each release
• Closing: Team Acceptance
• The testers are on the team and can immediately inform customer on quality
• The customer is on the team and can accept the work

Lean

• Designs are Evolutionary & Development is Incremental Only
• Limited up-front planning and control on releases
• Features are built based on immediate need, not market segments
• Services evolve underneath features to be both responsive and efficient
• Designs can be complex to maximize reuse, requiring smart but limited engineering work
• Key is to build "just enough"
• Teams: Emergent (Ad Hoc)
• Teams include only those needed at each stage
• This has a mix of people involved depending on current focus of work
• This minimizes costs immediately, but can cause issues in ownership and handoffs
• Integration and Testing: When Possible
• Lean projects are building on-demand without much up-front planning
• This results in an integration "when possible" approach
• As soon as the work is complete its integrated
• Examples are
• New discoveries introduced from R&D
• Fixes to working systems, such as bug fixes or replacement parts
• Upgrades and updates to legal documents once agreement is reached by parties
• Completing deal stages once customer is ready or response time expires
• Closing: Customer Acceptance
• Closing is based on customer acceptance only
• The work stays open until the customer is satisfied
• Customer is agreed to pay all costs until work meets satisfaction or project is cancelled
• Even testers are simply informing customers, usually without authority

Understanding the impact that the chosen PM Method has on Engineering is essential for any project manager. Depending on your domain of engineering different types of engineering may be possible or nearly impossible. Can one incrementally build a house? It wouldn't be allowed by the zoning boards, but it would also be dangerous!

At the same time, you only need a single general contractor and a small team to get those repairs done before putting a house on the market. You may have a fixed budget and need the best ROI to get that house at maximum attractiveness so buyers offer you the best bang for your investment buck.

And when it comes time to sell, can we understand the inefficiency of always re-writing the typical contract used for closing a house? Why redesign a whole new contract when you can just update and modify a template? The legal profession lives on templates.

Every aspect of work has its natural fit, but knowing that Agile delivers the maximum profit - can we make our projects more Agile-ready? What does that require from the customer and the design?

This is where the world of Engineering is headed today:

• All Industries are converging on Agile
• IT is integrating into every product - Andreessen's claim "Software is Eating the World"
• Examples of this trend include:
• Traditional going Agile:
• Building Information Modeling (BIM) - to drive the use of iterative planning and design for one or many buildings (e.g. Onuma System)
• Government Modular Acquisitions - to enable products of products and systems of systems in the government space (e.g. Open-Government Movement)
• Lean going Agile:
• Online Legal Products - grouping concerns of typical Lean processes into automated productized support (e.g. Legal Zoom)
• "Everything as a Service" - human resources, accounting, and marketing are now productized services or automated services for small businesses

Onuma Planning System Example

• Building Information Models to drive decisions on building investments
• Example of Agile approaches to modeling and planning large-scale requirements for buildings
• Modeled using "Rapid Planning Sessions" where
• Large ships called "Cutters" drove facility requirements
• Facility requirements then drove modeling new buildings and investment at Coast Guard sites
• All future scenarios were modeled using simulations in Google Earth
• Final details were architectural level, down to the "nuts and bolts."
• While this type of system may seem new, it's actually over a decade old
• This allows for iterative through otherwise static, top-down design processes with many interconnected planning details
• All the stakeholders get in a room
• The buildings are simulated in real time
• Architects, Interior Designers, MEC vendors, and Construction can all contribute to designs in real time
• Result is low costs in construction and significantly reduced numbers of change requests

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)