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