Agile Government and Concurrent Engineering

Saying “Agile Government with concurrent engineering, evolving CDRLs and controlled-scope contracts” sounds like an oxymoron – or a wild hallucination – but it is not. Just because achieving such an outcome may exceed the current knowledge base and skill level of some contracting officers (KOs), program managers (PMs) and acquisition professionals does not mean the FAR or DFAR prohibits it – or that logic precludes it. In fact, as complexity, uncertainty and risk rise the real world demands it!

Such demands require knowledge and skills growth so that leadership expectations and acquisition execution are enabled so developing solutions and work products proceeds through defined steps of learning and improvement. It is known as an Empirical approach – transparency, inspection, and adaptation - where every iteration produces measurable value. It has been around a long time and proven its value. It is doable using both FAR and non-FAR government methods. And it can be managed and controlled using Earned Value techniques.

For it to happen, sometimes teams must embrace concurrent engineering. Concurrent engineering (sometimes called simultaneous engineering) uses integrated, overlapping tasks in repetitive cycles to produce desirable outcomes. Think of it as a bicycle with round wheels climbing a hill instead of stacking building blocks to scale a wall.

Concurrent Engineering Benefits

The initial benefit of concurrent engineering is how it helps stakeholders conquer IKIWISI, that tendency to say, “I don’t know but … I’ll Know It When I See It” when you ask them to provide specifications for what they want.

The illustration of helping a stakeholder refine their request for a “truck” into a specification for exactly what they want maybe an oversimplification, but the real world is full of examples. In our book, Agile Government Contracting, 2nd Edition, we cite the example of the United States Marine Corps (USMC) acquiring an Expeditionary Fighting Vehicle (EFV). The program goal was to replace the aging fleet of amphibious troop transport vehicles. They assumed that the replacement vehicle would be track-based simply because the old ones were. However, the winning bid for the new Amphibious Combat Vehicle (ACV), which had requirements based on the EFV, delivered a vehicle with tires instead of tracks. ?

Another important benefit of concurrent engineering is that it overcomes the “Project Scheduling Conundrum. During our many years of leading programs and enterprises we have encountered a strange phenomenon, affectionately called the Project Scheduling “Oxymoron” or “Conundrum.” It manifests itself in the following way. First, every experienced leader and PM agree that most (many say “All!”) projects run out of time and budget before they run out of scope. Second, they then plan the project for maximum efficiency under the assumption that the entire scope will be completed before the project runs out of time and budget. Third, even though the first point contradicts the second point, they don’t seem to notice the logical fallacy of scheduling based on maximum efficiency without considering the need to effectively deliver priorities… and the error compounds until the project becomes a disaster!

Concurrent engineering is a rational, logical approach to planning and scheduling based on effectivity (priorities) first and efficiency second. Even with FFP contracts, if the Program involves high complexity and uncertainty, where a discovery and development model is best aligned to the probability of success, the assumption that scope is fixed and cost and schedule are flexible is a logical fallacy. Deciding to contract for what is required instead of how it will be developed is a key factor for unlocking the insight needed to achieve Program agility.

Concurrent engineering is more common than many practitioners realize. Many industries and programs operate with a mix of formal and informal TDD processes. One example is the construction industry, where the blueprints are subject to a relatively informal TDD process of customer review until they pass the “test” of customer expectations. Concurrent engineering of the various subsystems – electrical, plumbing, fire suppression, for example – are being done while the customer is finalizing their vision of the grand entry or building facia or roof fa?ade is occurring. A similar process occurs when another critical stakeholder – the Building Department – gets involved, and the blueprints go through additional concurrent engineering until they pass the minimum standards defined in the Uniform Building Code.

To make concurrent engineering work, acquisition teams must accept three principles. Avoiding finish-to-start scheduling can improve outcomes. Embracing uncertainty is not optional. Starting separately but finishing together is doable.

Concurrent Engineering Risks

When an acquisition faces high levels of complexity, uncertainty or risk, solution development can only be successful using an Empirical approach that produces measurable value every iteration. Given that complexity, uncertainty, or risk are an unavoidable part of the acquisition environment it makes sense to recognize that concurrent engineering has proven its value. It is also helpful to realize it is doable within government regulations, such as FAR and DFAR, and can be managed and controlled using Earned Value techniques. Neither of those truths, however, means that there are not concurrent engineering risks to address.

The most common collision occurs when Finish-to-Start (FS) scheduling practices attempt to plan and predict precise outcomes. The conflict occurs because FS practices assume stable activity-focused units of measure, which is not rational given the complexity and uncertainty. Alternately, concurrent engineering practices assume unpredictable result-focused units of measure. For an acquisition planning to be rational in a changeable environment scheduling must be based on the priority of the deliverable (outcome) not the amount of activity (hours, effort).

A second common difficulty comes from the concept of starting an activity before a predecessor has finished. Understanding that starting separately does not undermine or compromise finishing together seems counterintuitive to many practitioners. It sometimes helps to consider the analogy of running a 400-meter relay race around a track. Notice that because outside lanes are progressively longer, runners in those lanes begin the race further ahead on the track to ensure each runner covers the same distance, making it possible to judge the winner. Also notice that the recipient of the baton starts running before the person carrying the baton reaches them so they can maintain the pace while they synch up for the handoff. Lastly, notice that the winning team is not always the one with the fastest runners, but 100% of the time the winner is a team that did not drop the baton!

Maintaining an accurate, comprehensive understanding of the actual progress of the solution development effort, that is a holistic view not an activity-by-activity view, must be the reason for working iteratively and using concurrent engineering practices.

And now it is time for me to stop before this post accidentally becomes my 11th book!

How Do You See It?

How do you see your team achieving better results by using concurrent engineering practices with overlapping work elements? Please share your thoughts and enrich us all.

John Stenbeck, PMP, CDAI, DASSM, PMI-ACP, CSM, CSP , Michael Santens, DPA, PMP, CPCM, Fellow , Jason Glavich, PMP , Nicolas M. Chaillan , Lily Zeleke , Dr. Bemis Ikejiofor , Rich Yancy MBA, PMP, CSM, CSPO , Chase Eiserman , Heidi Shyu , Sekhar Prabhakar , Brett Harry , Chendra Conklin, CPCM, CFCM , Alp Sezen , Larry Rentz, PMP , Joel Dimaapi , Jason Knudson , Dr. Dolores Kuchina-Musina , Dr. Jamie Billig , Jack Ryan , Kyle Fox , Graham Plaster , RyAnn Elizabeth McCoy , Benjamin R. , Jamie Dufrene , Steve Visokay, PMP, DASM, PMI-ACP , Sabra Horne

#agile #pmi #leadership #greatpm