Making Big Projects Lean: Organize Teams By Function

Josh,

I'd suggest a better way. The way large manned spaceflight programs work, the way large bio-pharma programs work (under our guidance).

Organize by "deliverable" or "outcome."

There are some direct tangible benefits:

1. The deliverables teams have clear, concise, and measurable measures of performance. Technical performance, measures of effectiveness, and KPP/KPI connected to the outcome rather than role or function.

2. Incremental measures of progress from planned incremental deployments for the final product, rather than the work effort or role.

Functional decomposition is "poor" decomposition of the WBS - as your wonderful book states - along with the new MIL-STD-881C (not a standard and mandate for all FAR procurement).

To address each of your items

1. Systems/subsystems become disjointed - don't let this happen by defining the systems architecture in sysML and the programmatic architecture in the Integrated Master Plan. These do define ALL the interfaces, dependencies, data and process flow between the Systems/Subsystems.

2. Define the communications in a formal sysML ICD (Interface Control Document). These become the "test driven development" specification. It's a "build to spec" for the interface.

3. Teams become insular - this is the role of the Chief Engineer and the Systems Engineering staff as well as the Control Account Manager and the Engineer Project Manager, your choice. She is the "facilitator" of all things to be facilitated.

4. Standards all of the place - "don't do stupid things on purpose." This is the role of systems engineering.


Posted: Dec 31, 2011 2:44 PM

Thanks for the comment Glen. You can (and should) still organize the WBS by deliverables, this is just a different sort of deliverables-based decomposition. The work packages become feature-centric as opposed to subsystem-centric. In the beginning it's going to be focus on platform building, similar to digging, pouring foundations, and framing in construction. With software systems, we can build those frameworks for user interfaces, job control, processing of like kinds, database infrastucture, etc simultaneously. One the foundations are laid, it's a coordinated team effort to implement features (deliverables) across the entire system. It's not done until a demonstrated capability exists.

From my experience, most KPIs are vanity metrics. That's probably not true in all cases of course. But the things to monitor in a lean system with single-piece flow like this are feature cycle time and WIP. Measuring the velocity of the whole system (it's the only thing that counts).

I'm tying this on my iPhone and probably have more to say, but my wife is glaring at me! :-)

Posted: Dec 31, 2011 5:01 PM

Haha, typing, not tying (that's what I get for responding on a small mobile device :-)

Another point I wanted to make that is from what I talked about in my book... organizing your WBS by the teams that will carry it out is also a mistake. Flipping that around, there's no reason in most cases, especially with a software system, to organize your teams in the same way your WBS is organized. Although what I'm really advocating here is simply a different method of categorizing the deliverables on large projects.

From an EVM perspective -- we claim earned value when a subsystem has a release and all of the discrete tasks that are completed along the way. But in the end, a subsystem release that doesn't get integrated into the system as a whole hasn't earned any value in my book. We can't use it yet to produce throughput through the entire system as a whole.

In a feature-driven deliverable world, it's 0-100 and you only claim value when a feature has run it's full course and is now available to end users (even if that's a group of operators who need to play with the system before it goes live). Now I'm thinking purely in software systems terms now. When it comes to hardware and launch vehicles a different method is probably going to work better.

Feature-driven development like what I've described in this series means delivering new functionality (deliverables) in a low cycle-time iterative manner and in a fully integrated and tested manner. Verified and validated.

On ISDs and ICDs... my focus here is primarily within a single project contractor team and those can run very large on some of these projects. ISDs and ICDs may yet be a necessity if you are only able to do continuous integration internally. On my project for example I could easily see the 8 or so subsystems we have being seen as a single system when it comes to integration. Those internal ISDs and ICDs are only necessary because the integration is so disjointed and only happens at arbitrary milestones. When you are releasing once or twice a week (or more) you are testing and honing those interfaces on a continuous basis and because the teams are organized around function instead of subsystem these 'subsystem-to-subsystem' interfaces aren't really any different from interfaces internal to components in any individual subsystem.

Thanks again for your comments Glen, I really enjoy the discussion and helping me think through this.

Posted: Dec 31, 2011 10:17 PM

Happy New Year, Josh.... (And Glen et al)



Why limit ourselves to only a SINGLE WBS? Why not enable MULTIPLE sorts?



The Construction Specifications Institute (CSI) recognized this need way back in the 1960''''''''s with their Masterformat and Uniformat. (Masterformat was by trades, much along the lines of what Josh described above, and Uniformat was by component) http://www.csinet.org/Main-Menu-Category/CSI-Store/6.aspx



Then Norsok Z-014 came along about 25 years ago especially for the offshore oil and gas sector and created a three dimensional model- by trade and component, but also by PHASE. http://www.standard.no/PageFiles/951/Z-014.pdf



And now we have Omniclass, which is a collaboration between CSI and ISO et al which offers 15 DIFFERENT ways to sort or look at our project. http://www.omniclass.org/



And if you want to see some of the research being done on how to use or get the most from these multi-dimensional databases, Jean Yves Moine has been doing considerable research and writing on this topic. http://www.linkedin.com/groups/3D-Work-Breakdown-Structure-3D-35313.S.82579516?qid=dbe7dc17-4206-4b46-9a62-ae1879fd3ded&trk=group_most_popular-0-b-cmr&goback=.gmp_35313



Bottom line- different stakeholders need to see the project sorted different ways and we need to be advocating as a "best practice" two major concepts- 1. the use of STANDARDIZED (as opposed to custom or ad hoc WBS) structures and 2. the use of multiple sort WBS. (MINIMUM by component, by trade or function and by phase)



BR,
Dr. PDG, from Boston, MA, USA
http://www.build-project-management-competency.com



Posted: Jan 1, 2012 5:28 AM

PS: More from Jean Yves Moine- http://3d-wbs.blogspot.com/

Posted: Jan 1, 2012 5:31 AM

Josh,

Yes WPs match the lowest tier of the WBS and produce a single outcome. Tasks in the WPs shoudl have 0/100 measures of progress or apportioned milestones. All other measures become subjective and "spoil the soup" of measures of physical percent complete.

"Pouring concrete" is a role or function but not an outcome. "Pouring" is needed to accomplish the outcome, along with other activities in the work package. The outcome may be "Lower Level Parking Pad Complete."

And it''s measurement of outcomes that you want your project to use as a measure of progress to plan.

Posted: Jan 1, 2012 12:15 PM

Paul,

Your description is still ONE WBS. just pivoted in a variety of ways. Otherwise you violate a fundamental rule of GAAP and other finance cost integrity rule.

Actual multiple WBS provide no transitive closure in the database of cost traced to work.

Pivot tables are our friends for sure, so multiple views of the singular WBS provides that in all ERP systems.

Posted: Jan 1, 2012 12:19 PM

Semantics, Glen.


These are not simple pivot tables, but holistic stand alone WBS/CBS structures,

They can be used alone or in conjunction with one another.


And as noted on previous occasions, while in your world, you trace costs to the WBS, in my world (hard money contracting) we trace costs to the activity level.


But clearly, despite GAAPS and PMI and a host of other organizations, the days of the single WBS are soon to end in favor of multiple viewpoints, with the ACTIVITIES being the primary cost management tool, NOT the WBS. (As noted in your comment to Josh) Costs are accrued at the "Placing Concrete" level and not at the "Lower Level Parking Pad"



BR,

Dr. PDG, from Boston, MA, USA

http://www.build-project-management-competency.com



Posted: Jan 1, 2012 1:39 PM

I agree with you Glen. I'm not talking about using anything but deliverables to define scope or as a means of measure. "Feature A, B, C" are deliverables. Small batch sizes mean these have a short cycle time, and nobody gets credit for any earned value until the whole feature is 'done' - which by definition here is now entirely developed, integrated, and tested for verification and validation.

Posted: Jan 1, 2012 2:15 PM

Josh,

My preference and experience that informs that preference is to focus exclusively on "outcomes" - the paradigm of Integrated Master Plan and Integrated Master Schedule.


A "feature" could be an outcome, but better is a "capability." "We need the capability to fly to ISS, dock, stay for 6 months, and return safely with 4 PACS on board. Or something like that. The concrete example (pun) might be "we need the capability to park FedEx trucks at the dock without fracturing the parking surface for 4 yars with a specified load factor.


Now you can define the outcomes of Work Packages that will result in the capability.


These WP would be at the terminal nodes of the WBS.


The notion of making a WBS contain the location, and other attributes "might" be useful, but that information does not change another primary role of the WBS - to collect cost for the "outcome" NOT the activities of the work package. The cost of the activities in the WP are there by definition in the BCWS loaded schedule (or some arrangement of work).

Iif you take this approach the ABC paradigm comes for free ABC you get a clean WBS (transitive closure is maintained, http://bit.ly/sz5X60), AND you get a credible PMB. Then you can "derive" those 3D pictures that Paul like while maintaining the integrity of the database in the accounting system. And you can report cost by activity, cost by outcome, cost by location, et al.


I say this from architecting program cost and schedule models in SAP and others, where nearly everyone on the program wanted some "special" view of the data for their personal paradigm reason. But at the same time assuring transitive closure for that data for external surveillance.


Regarding your short cycle time, the question "how long are you willing to wait before you find out you''''re late," informs what it means to be short. FAR 34 requires once a month. Practice usually means weekly EV with 0/100 tasks with BCWS assigned to them to get the ABC as all the other pivot table attributes for the data that is in separate columns of the IMS.


Those terms you''''ve got at the end are in the WBS Dictionary for the EVT narrative for the WP. All of those suggestions are found in the EVM System Description of all the programs I work.

Posted: Jan 1, 2012 6:47 PM

Paul,
Since you have acknowledged you lack experience in the FAR contract world, you may be pleased to learn that ABC is part of the financial baseline in FAR contracts. Both are used, one is not more important than the other. ABC is commonly found in production - Post MS C and WP accounting if found in Pre MS C up to LRIP. Once in FRP or LRIP repetitive processes no long provide insight to future performance using discrete EV measures.

Posted: Jan 1, 2012 6:51 PM

Glen, your use of 'capability' and my use of 'feature' are interchangeable in the way I mean 'feature' -- it's a use case or in other words a capability of the system...just at a level and structured in such a way that we can deliver this feature or capability in a short cycle time. These are usually components of a much larger capability. By having the whole value stream (all project stakeholders) focus on a single capability at a time we can sequence these to provide feedback on fundamental capabilities first and get those capabilities in the customer's hands much, much more quickly than a traditional big project in this space.

I don't think this conflicts with any of the planning elements we've discussed so far in this thread. The one thing it does destroy is the idea of multiple levels of integration and testing. Those go out the window with the approach I'm suggesting. There is no need for all that overhead when you are providing all the value we derive from those reviews instead on a real-time basis with continuous integration.

Posted: Jan 1, 2012 10:07 PM

Josh,

Capabilities provide outcomes to the buyer. Here's some samples of capabilities found in programs I've worked recently

(a) We need the capability to pre?process insurance claims at $0.07 per transaction rather than the current $0.11 per transaction.

(b) We need the capability to remove 1½ hours from the retail ordering process once the merger is complete.

(c) We need the capability to change the Wide Field Camera and the internal nickel hydride batteries, while doing no harm to the telescope.

(d) We need the capability to fly 4 astronauts to the International Space Station, dock, stay 6 months, and return safely.

(e) We need the capability to control the Hell Fire Missile with a new touch panel while maintaining existing navigation and guidance capabilities in the helicopter.

(f) We need the capability to comply with FAR Part 15 using the current ERP system and its supporting work processes.

These capabilities will have "features" that can be used to deliver these capabilities that in turn fulfill some Concept of Operations, a Mission, or a Business Case.

But I'd suggest that while Capabilities possess features, they are not interchangeable in the domains that make use of Capabilities Based Planning, http://bit.ly/vfM74J and http://bit.ly/uKGoRf

Like most things in the PM world, multiple definitions exist for similar domains. But the subtlety comes when we start to measure performance and the units of measure are not defined sufficiently clearly to assess progress in a meaningful way.

Capabilities (or possibly features) must be connected to "business outcomes" or "business effects"

So I'd say you're right in principle, it's the practice on a specific program in a specific domain that creates gaps in the conversation if we're not sitting in the same room.


Posted: Jan 1, 2012 10:22 PM

Josh,

Here's some more "Capabilities" background http://bit.ly/rVNiGh. Figure S.2 is an example of a "capabilities" assessment. These are different from "features"

Posted: Jan 2, 2012 12:42 AM

Hi Glen,

Not to rehash this for about the thousandth time, but IF the projects initiated, planned, executed and controlled by the US government were consistently delivered "on time, within budget, in substantial conformance to the technical requirements and substantially accomplished the purpose for which they were undertaken" then I would eagerly listen to and even be willing to adopt what you advocate.



However, given the rather abysmal track record of the public sector, the US Federal Government in particular, (see Butts et al) I hardly see that as justification for your continuing support and advocacy for project and program management as done by the military-industrial complex.



Bottom line- "Business as Usual" by the US Government cannot continue and I suggest that the military-industrial complex needs to look to the private sector to see how we do project management "leaner".



BR,
Dr. PDG, Boston, MA
http://www.build-project-management-competency.com





Posted: Jan 2, 2012 5:14 AM

@Glen - Thanks for sharing your thoughts and the link. Now that we're speaking the same language, I believe what I'm referring to as features comprise capabilities as you've described them and in the paper by Davis. It's going to take many interim steps to deploy a capability defined as they are at a more macro level.

I'm focusing solely on software-driven systems since that's where the majority of my experience is from. I'd have to defer to someone like my friend Hal Macomber for the application of Lean in projects involving physical construction.

I'm advocating an approach to implementing capabilities that results in smaller pieces of that capability ready for operations with 'early and often' releases. The feedback loop from those releases in the hands of the people who will be operating the software, equipment, etc. is critical learning that can be leveraged to make a better product more quickly and with less rework.

For example, with the Hell Fire Missile touchpad control system:
-Define the needed capability in clear terms (planning methods we currently use are fine for this, as long as they stay fairly high-level.)
-Define and sequence the features underlying that capability in such a way that they can be fully implemented by themselves to gather feedback from real operators. If you can't demonstrate a partial capability (feature) to the end-users, that feature is not 'done'.
-produce a minimum viable product which is essentially a wireframe mockup of a touch panel.
-Simulate hardware with software as much as possible. An iPad or tablet PC could be used.
-1 or 2 times a week, you have a new feature ready that contributes to the overall capability. Daily would be even better. Sometimes those releases are updates to existing features based on user feedback.

Perhaps in this scenario you have a UI team, a missile control team, etc. (I don't know enough about this type of project to say). The teams who will be responsible for implementing the real control systems are the ones mocking up the simulated control systems in coordination with the UI team. They get the most learning by simulation, at a low cost and are heavily engaged with the end users this way.



Posted: Jan 2, 2012 12:15 PM

Glen, Josh et al,


Below is a recent article from Aviation Week & Space Technology Jan 02 , 2012 , p. 23 "Onward Through The Fog" that backs up my earlier rant about using the DoD "standards" as any kind of a "best" or even "good" practices benchmark.



The Government Accountability Office issues a new, sobering critique of the Pentagon’s indecipherable bookkeeping. Indeed, according to the latest missive, the military’s financial statements are so miserably kept that the congressional accountants cannot make sense of them at all—even if they say so via jargon only auditors can appreciate. “As was the case in 2010, the main obstacles to a GAO opinion on the accrual-based consolidated financial statements were: (1) serious financial management problems at the Department of Defense (DOD) that made its financial statements unauditable, (2) the federal government’s inability to adequately account for and reconcile intragovernmental activity and balances between federal agencies, and (3) the federal government’s ineffective process for preparing the consolidated financial statements.”



Glen in particular- PLEASE- stop trying to defend what the DoD/DoE is doing or advocating that somehow what the DoD/DoE et al are doing represents some sort of standard we should be respecting/adopting and start to become an activist, speaking OUT against the wasteful and inefficient practices of our US Federal Government. Please do so BEFORE they push the country further down the roads towards bankruptcy (or hyperinflation)



BR,
Dr. PDG, freezing in Boston
http://www.build-project-management-competency.com






Posted: Jan 3, 2012 10:24 AM

Paul,

Your confusing accounting with program management - again. The article speaks to the issues as

“As was the case in 2010, the main obstacles to a GAO opinion on the accrual-based consolidated financial statements were: (1) serious financial management problems at the Department of Defense (DOD) that made its financial statements unauditable, (2) the federal government’s inability to adequately account for and reconcile intragovernmental activity and balances between federal agencies, and (3) the federal government’s ineffective process for preparing the consolidated financial statements.”

This is not the topic I speak to here.

You seem to be confused further about the agency accounting systems and the contractor accounting systems, lumping everything into one tidy pile and then ranting - as you seen to enjoy doing - that you have a better approach.

Nice try though.

Posted: Jan 3, 2012 10:42 AM