Acquisition Acceleration can reduce the risk of delivering weapons systems that are technologically obsolete or late-to-need. Acceleration can also reduce the risk of waste associated with delays. Shortening the development cycle time helps teams learn faster and thus reduces the risk of uninformed decision-making.
Accelerated programs tend to have a greater degree of personnel stability, which reduces the risk of losing key personnel and reduces the cost of on-boarding new personnel. Faster programs are less likely to be impacted by changes to the threat environment or changes in technology, and thus are less likely to deliver a system that is operationally irrelevant, technologically obsolete, or both.
But going too fast can lead to hasty decision-making and cutting corners inappropriately. An accelerated team has a heightened risk of overlooking a crucial step in the process, overlooking a valuable opportunity, or of making a decision without the benefit of a critical piece of information. Going fast can also increase the risk of burnout, so program leaders should make sure the pace is sustainable.
Program leaders must consider how speed affects the risk items on their watch list. It is important to recognise that acceleration can be an important part of a risk reduction strategy, and should not be viewed simply as a high-risk proposition. Program leaders must take steps to ensure the acceleration strategy is aligned with the program’s overall risk appetite, and should encourage “speed with discipline” as a guiding principle.
Experiments come in many forms. The simplest form involves an intervention followed by an observation followed by reflection. The intervention introduces a change, while the observation records the impact of that change and the reflection translates the experience into learning. This formula can be applied to experiments related to processes, technologies, documentation, requirements, and other program activities. It is important to recognise that the only failed experiment is one we do not learn from.
Experiments are most effective when done as part of a regular practice rather than as isolated, occasional activities. We ask a question, perform an experiment that produces an answer… which leads to another question.
Clear, consistent communication from leadership, across multiple channels, is essential to guide individuals to operate confidently at increased speed. Senior executives, senior staff, and middle managers must regularly communicate to the workforce, using meetings, program and portfolio reviews, memos and emails, public speeches, articles, and other forums, to reinforce the desired norms and behaviors. Start with Why. Leaders are able to inspire others by first communicating why they need to do what they do. Why do we need to deliver capabilities faster?
Going faster is not just a tag line for us; it’s a serious business about keeping the force competitive and dominant. It starts with our warfighters, everything is about their mission. We are competing against peer adversaries who can match its technology. At a time of unprecedented technological advancement, we must have the fastest acquisition system to keep on winning.
The strategy is fairly simple: empowering program managers with design tradespace, prototyping, flexible contracting, and appropriate decision authorities to take the reins of the programs. Resulting organizational byproducts—speed, agility, and accountability. Must expand human-driven approach: delegating decisions to the lowest appropriate level; increasing rapid experimentation and prototyping for “fast failing”, early risk reduction, and keeping flawed concepts out of programs of record; and expanding use of commercial technology and practices, including designing for upgradeability and sustainment.
Empowering decision-making as close as possible to the sources of the most critical information reduces decision latency and enables the team to integrate more of the relevant data into the decision. A team that operates with the shortest possible decision-making path is more able to respond and adapt to rapidly changing conditions, move faster through its own decision-making process, and inform or implement decisions made higher in the organization.
Allowing decisions to be made at lower tiers of the organization also frees up capacity for upper level leaders to take broader strategic actions and clear away the obstacles that degrade implementation. And most importantly, the individuals who are personally involved in decision-making take greater care throughout the process and feel greater ownership for the outcomes of the decision, making this a best practice and key enabler for acceleration. As a general principle, issues should be resolved at the lowest level possible.
Decision authority must be accepted as well as delegated. While senior leaders can initiate this change, personnel in lower-tier organizations must be willing to accept the accountability that accompanies empowerment. Both parties have a role in avoiding an overly cautious approach where all decisions are automatically pushed to the highest possible level.
Requirements set the foundation of an acquisition program. They must be clearly defined, realistic, affordable, and testable. Given the rapidly changing pace of operations, technologies, and threats, DoD cannot afford to spend two years authoring and coordinating JCIDS documents to lock down requirements for a decade or more.
Effectively scoping a program, increment, or release is a critical element to being able to deliver capabilities in a timely manner. Far too many programs attempt to do too much at once which risks delivering any capabilities. The key is to scope the work that leverages mature technologies, is affordable within the available budget, and can realistically be delivered within the desired/needed timelines.
To help meet expected delivery dates, some degree of flexibility is needed in the requirements. The operational command or business unit should convey requirements via high level objectives for the acquiring organization to deliver as much capability as possible based on budgets, schedules, risks, and other factors.
It’s better to have an 80% solution today than risk the entire program trying to get it perfect. If your program is under pressure to deliver sooner, ask yourself: What functionality could be removed or deferred and still achieve the desired outcomes? If you effectively scope the program and manage requirements as outlined below, you should be able to regularly deliver capabilities.
How a program is structured is critical to determining when capabilities can be delivered to users. After decades of attempting to build exquisite large complex systems via a single “big bang” approach with limited success, agencies have embraced more iterative, spiral, and Agile development with greater success. Breaking the scope of work into multiple smaller releases enables organizations to be responsive to changes in operations, risks, budgets, priorities, contractors, technology, and more.
A program’s acquisition strategy must assess the environmental factors and structure development, integration, and delivery accordingly. A major weapon system that delivers all of its planned capabilities after 10–15 years will not satisfy its customers as much as a system that delivers 60 percent of its capabilities in 6–8 years, with the program office involving the customer in iterative deliveries thereafter. This principle holds true for acquisitions from small software programs to large aircraft systems.
“Streamline rapid, iterative approaches from development to fielding. A rapid, iterative approach to capability development will reduce costs, technological obsolescence, and acquisition risk. The Department will realign the incentive and reporting structure to increase speed of delivery, enable design tradeoffs in the requirements process, expand the role of warfighters and intelligence analysts throughout the acquisitions process, and utilize non-traditional suppliers.
Over the life of a program, a considerable amount of time is spent developing strategies, coordinating them within the Program Management Office PMO and the many external stakeholder and oversight organizations. PMOs will spend months and years developing thousands of pages of documentation and hundreds of Power Point slides and spend countless hours in meetings.
How much of that contributes to delivering the capabilities? While there needs to be sufficient rigor to ensure the program is addressing the fundamentals and complying with required elements, months and sometimes years are lost in seeking consensus from dozens of organizations to ensure the documentation and presentations are “perfect” or low enough risk to proceed. Many executives encourage tailoring processes and documents to what makes sense for the program, and while there are some barriers, programs should leverage this empowerment to streamline smartly to deliver capabilities sooner.
The “start up favors experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big design up front” development. New ventures of all kinds are attempting to improve their chances of success by following its principles of failing fast and continually learning. And despite the methodology’s name, in the long term some of its biggest payoffs may be gained by the large companies that embrace it.
In acquisitions, the conventional wisdom is to define a program’s requirements and acquisition strategy upfront to describe the operational challenges and proposed solution. Budgets are determined early, often with a two-year lead time for Congress to appropriate funds. These plans are written before the system is developed based on the assumption that the program’s design and risks can be worked out ahead of time. After 5-10 years of development, developmental test, and production of initial quantities, users are first able to see the system in operational test. It is at this point when agencies realize the program’s features don’t effectively address the operational challenges as they weren’t effectively defined upfront or the environment has changed significantly over the last decade.
Ask potential users, purchasers, and partners for feedback on all elements of the business model, including product features, pricing, distribution channels, and affordable customer acquisition strategies. The emphasis is on nimbleness and speed: New ventures rapidly assemble minimum viable products and immediately elicit customer feedback.
Unlike yearlong product development cycles that presuppose knowledge of customers’ problems and product needs, agile development eliminates wasted time and resources by developing the product iteratively and incrementally. It’s the process by which start-ups create the minimum viable products they test.
An acceleration team should aim to only produce the documents that are useful and needed to manage the program, rather than writing “compliance only” documents which exist only to satisfy the interests of an outside stakeholder.
If there are requirements in policy that don’t make sense for your program, identify them and offer recommendations to tailor or waive that requirement. Be sure to include the information on the waiver authority organization, duty title, etc.
Understand the difference between a requirement that a program must have an XYZ strategy which complies with an organization’s template vs a requirement that a program capture and convey the core elements of their strategy to decision authorities and stakeholders. Ultimately the documentation is designed to ensure the program office has done sufficient critical thinking to execute the next phase of the program.
Develop an outline of the documentation the program office plans to compile, with the intended content in each document. Identify how this proposed set meets the documentation requirements. Present the proposed documentation outline with the decision authorities early in the process to solicit their approval. As some functional oversight organizations may resist tailoring their functional document, this may require the program’s leadership chain assuming they agree with the approach to engage on this is how we need to move forward for the program.
Program offices should be empowered to tailor documentation to their program’s environment. Based on type of acquisition, size, scope, complexity, and risk, the documents are there to help the program develop and execute sound strategies. The documentation is not intended to ensure compliance with some oversight organization’s standardized approach. Oversight organizations should develop and publish templates and guides for each major document to help the program offices apply the best practices from past programs and ensure critical areas are addressed.
A small, empowered, high-performing team is often able to deliver focused impact more quickly than larger teams or organizations made up of multiple teams. One of the primary reasons large teams or organizations don’t move quickly is the amount of formal coordination required before decisions can be made and actions taken. In a small team, members often work nearby and conduct regular brief check-ins to ensure each member is aware of the others’ efforts and challenges. This compact design enables the team to accomplish its purpose quickly and efficiently.
The number of communication lines between individuals multiplies when the team gets bigger, making it increasingly difficult to coordinate activities and sustain a high tempo. To facilitate control, large teams are broken into multiple smaller teams, and required coordination between them further increases. Over time, a greater proportion of the team’s resources are diverted to meetings, reports, emails, and other administrative activities to maintain alignment and coordination between the components. Thus, keep the team small to move fast.
Have a problem-solving mindset A key quality of a high-performing team is their ability to overcome obstacles. In a workplace, nothing is ever smooth-sailing. Problems come in many forms; it could be a delay from a supplier, technical breakdowns or an idea that didn’t translate in the real world.
1. Leaders support experimentation as a learning method
2. Workforce understands the methods, procedures, and purposes of experimentation
3. Workforce has access to resources e.g. a sandbox environment that replicates the operational environment and can be used for doing experiments without impacting operations
4. Workforce has access to mechanisms for sharing observations and lessons learned
5. Introduce experimentation principles and practices to team.
6. Quickly design and execute simple, informative experiments.
7. Craft a “campaign of experiments” to provide regular pace of learning and discovery.
8. Leverage existing communication reporting channels to inform leadership.
9. Pass along leadership guidance insights to your team so they understand the Big Picture
10. Start communications with the “why go fast” first — then articulate the “how.
11. Review policy on decentralized decision authority and publicize local application for your project.
12. As specifically as possible, identify decisions that can and should be delegated to lower levels.
13. When in doubt, delegate Assuming no explicit statutory or regulatory policy preventing the delegation
14. Establish shared expectations about decision-making authorities.
15. Continuously watch for instances where decision-making is slowed down by unnecessary involvement by higher-level authorities.
16. Encourage team members to sign up for additional training.
17. Arrange a group training session for the team.
18. Take a course yourself and share the lessons with the rest of the team.
19. Challenge a team member to research, develop, and deliver a course.
20. Who are the formal and informal leaders in the organization?
21. What messages are these leaders currently sending, and are these messages consistent with the desired culture?
22. What new messages should the leaders begin sending, in order to introduce the desired culture?
23. What measures are the leaders currently using to assess the organization’s performance, and how do these align with the desired culture?
24. What measures should the leaders focus on, in order to reinforce the desired culture?
25. What incentives are currently in place, and do they align with the desired culture?
26. What new incentives and rewards can be established to reinforce the desired culture?
27. Have leaders identified groups within the organization that already exhibit the desired culture?
28. What steps are leaders taking to hold up these groups as models or exemplars for others to emulate?
29. Don’t overly define the solution – Operational sponsors outline high level objectives
30. Empower “product owner” to set vision, shape requirements, and actively collaborate with users, acquirers, developers
31. Lower level requirements require flexibility to be responsive to changing operations, threats, risks, performance, and budgets
32. Requirements for current release should leverage only mature technologies and/or COTS solutions
33. Delivers capabilities to the users quickly
34. Enables iteration based on user behavior and feedback
35. Restrain system complexity, avoid over-engineered solutions.
36. Demonstrate and measure value accurately; rapidly iterate deliveries
37. Involve non-traditional vendors
38. Provides clarity and builds consensus about the problem to be solved.
39. Facilitates prioritization and focus, reduces wasted effort and mis-aligned, unproductive activities.
40. Identify an area that is overly complex or contains a large collection of unsorted ideas, designs, components, or facets.
41. Assess the outcome – briefly discuss whether the smaller set of remaining items is a better collection than what you started with.
42. A program in the early stages should plan to structure the delivery of systems or services of the full envisioned scope in multiple iterations.
43. Allow for iterative deliveries without having to meet the full set of performance requirements envisioned for the complete solution.
44. Understand the potential constraints and tradespace in determining iterative breakpoints based on major groupings of scope or a repeatable timeline e.g. annual deliveries
45. Identify dependencies with external programs and discuss with stakeholders the required functionality, interfaces/integration, and timelines.
46. Acquisition, contracting, engineering, and testing strategies should reflect the iterative structure to include the processes, resources, and decisions needed to field each release.
47. If establishing a new capability area, explore the opportunity to structure high level requirements via a new Portfolio
48. Setup a series of discussions with stakeholders from the operational/requirements organizations on managing requirements with greater agility.
49. Review existing contracts in your buying office to see if similar work is being done by the same contractor or subcontractor.
50. The best way to cure a sleepless night—yours and theirs–is to take action.
Accelerated programs tend to have a greater degree of personnel stability, which reduces the risk of losing key personnel and reduces the cost of on-boarding new personnel. Faster programs are less likely to be impacted by changes to the threat environment or changes in technology, and thus are less likely to deliver a system that is operationally irrelevant, technologically obsolete, or both.
But going too fast can lead to hasty decision-making and cutting corners inappropriately. An accelerated team has a heightened risk of overlooking a crucial step in the process, overlooking a valuable opportunity, or of making a decision without the benefit of a critical piece of information. Going fast can also increase the risk of burnout, so program leaders should make sure the pace is sustainable.
Program leaders must consider how speed affects the risk items on their watch list. It is important to recognise that acceleration can be an important part of a risk reduction strategy, and should not be viewed simply as a high-risk proposition. Program leaders must take steps to ensure the acceleration strategy is aligned with the program’s overall risk appetite, and should encourage “speed with discipline” as a guiding principle.
Experiments come in many forms. The simplest form involves an intervention followed by an observation followed by reflection. The intervention introduces a change, while the observation records the impact of that change and the reflection translates the experience into learning. This formula can be applied to experiments related to processes, technologies, documentation, requirements, and other program activities. It is important to recognise that the only failed experiment is one we do not learn from.
Experiments are most effective when done as part of a regular practice rather than as isolated, occasional activities. We ask a question, perform an experiment that produces an answer… which leads to another question.
Clear, consistent communication from leadership, across multiple channels, is essential to guide individuals to operate confidently at increased speed. Senior executives, senior staff, and middle managers must regularly communicate to the workforce, using meetings, program and portfolio reviews, memos and emails, public speeches, articles, and other forums, to reinforce the desired norms and behaviors. Start with Why. Leaders are able to inspire others by first communicating why they need to do what they do. Why do we need to deliver capabilities faster?
Going faster is not just a tag line for us; it’s a serious business about keeping the force competitive and dominant. It starts with our warfighters, everything is about their mission. We are competing against peer adversaries who can match its technology. At a time of unprecedented technological advancement, we must have the fastest acquisition system to keep on winning.
The strategy is fairly simple: empowering program managers with design tradespace, prototyping, flexible contracting, and appropriate decision authorities to take the reins of the programs. Resulting organizational byproducts—speed, agility, and accountability. Must expand human-driven approach: delegating decisions to the lowest appropriate level; increasing rapid experimentation and prototyping for “fast failing”, early risk reduction, and keeping flawed concepts out of programs of record; and expanding use of commercial technology and practices, including designing for upgradeability and sustainment.
Empowering decision-making as close as possible to the sources of the most critical information reduces decision latency and enables the team to integrate more of the relevant data into the decision. A team that operates with the shortest possible decision-making path is more able to respond and adapt to rapidly changing conditions, move faster through its own decision-making process, and inform or implement decisions made higher in the organization.
Allowing decisions to be made at lower tiers of the organization also frees up capacity for upper level leaders to take broader strategic actions and clear away the obstacles that degrade implementation. And most importantly, the individuals who are personally involved in decision-making take greater care throughout the process and feel greater ownership for the outcomes of the decision, making this a best practice and key enabler for acceleration. As a general principle, issues should be resolved at the lowest level possible.
Decision authority must be accepted as well as delegated. While senior leaders can initiate this change, personnel in lower-tier organizations must be willing to accept the accountability that accompanies empowerment. Both parties have a role in avoiding an overly cautious approach where all decisions are automatically pushed to the highest possible level.
Requirements set the foundation of an acquisition program. They must be clearly defined, realistic, affordable, and testable. Given the rapidly changing pace of operations, technologies, and threats, DoD cannot afford to spend two years authoring and coordinating JCIDS documents to lock down requirements for a decade or more.
Effectively scoping a program, increment, or release is a critical element to being able to deliver capabilities in a timely manner. Far too many programs attempt to do too much at once which risks delivering any capabilities. The key is to scope the work that leverages mature technologies, is affordable within the available budget, and can realistically be delivered within the desired/needed timelines.
To help meet expected delivery dates, some degree of flexibility is needed in the requirements. The operational command or business unit should convey requirements via high level objectives for the acquiring organization to deliver as much capability as possible based on budgets, schedules, risks, and other factors.
It’s better to have an 80% solution today than risk the entire program trying to get it perfect. If your program is under pressure to deliver sooner, ask yourself: What functionality could be removed or deferred and still achieve the desired outcomes? If you effectively scope the program and manage requirements as outlined below, you should be able to regularly deliver capabilities.
How a program is structured is critical to determining when capabilities can be delivered to users. After decades of attempting to build exquisite large complex systems via a single “big bang” approach with limited success, agencies have embraced more iterative, spiral, and Agile development with greater success. Breaking the scope of work into multiple smaller releases enables organizations to be responsive to changes in operations, risks, budgets, priorities, contractors, technology, and more.
A program’s acquisition strategy must assess the environmental factors and structure development, integration, and delivery accordingly. A major weapon system that delivers all of its planned capabilities after 10–15 years will not satisfy its customers as much as a system that delivers 60 percent of its capabilities in 6–8 years, with the program office involving the customer in iterative deliveries thereafter. This principle holds true for acquisitions from small software programs to large aircraft systems.
“Streamline rapid, iterative approaches from development to fielding. A rapid, iterative approach to capability development will reduce costs, technological obsolescence, and acquisition risk. The Department will realign the incentive and reporting structure to increase speed of delivery, enable design tradeoffs in the requirements process, expand the role of warfighters and intelligence analysts throughout the acquisitions process, and utilize non-traditional suppliers.
Over the life of a program, a considerable amount of time is spent developing strategies, coordinating them within the Program Management Office PMO and the many external stakeholder and oversight organizations. PMOs will spend months and years developing thousands of pages of documentation and hundreds of Power Point slides and spend countless hours in meetings.
How much of that contributes to delivering the capabilities? While there needs to be sufficient rigor to ensure the program is addressing the fundamentals and complying with required elements, months and sometimes years are lost in seeking consensus from dozens of organizations to ensure the documentation and presentations are “perfect” or low enough risk to proceed. Many executives encourage tailoring processes and documents to what makes sense for the program, and while there are some barriers, programs should leverage this empowerment to streamline smartly to deliver capabilities sooner.
The “start up favors experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big design up front” development. New ventures of all kinds are attempting to improve their chances of success by following its principles of failing fast and continually learning. And despite the methodology’s name, in the long term some of its biggest payoffs may be gained by the large companies that embrace it.
In acquisitions, the conventional wisdom is to define a program’s requirements and acquisition strategy upfront to describe the operational challenges and proposed solution. Budgets are determined early, often with a two-year lead time for Congress to appropriate funds. These plans are written before the system is developed based on the assumption that the program’s design and risks can be worked out ahead of time. After 5-10 years of development, developmental test, and production of initial quantities, users are first able to see the system in operational test. It is at this point when agencies realize the program’s features don’t effectively address the operational challenges as they weren’t effectively defined upfront or the environment has changed significantly over the last decade.
Ask potential users, purchasers, and partners for feedback on all elements of the business model, including product features, pricing, distribution channels, and affordable customer acquisition strategies. The emphasis is on nimbleness and speed: New ventures rapidly assemble minimum viable products and immediately elicit customer feedback.
Unlike yearlong product development cycles that presuppose knowledge of customers’ problems and product needs, agile development eliminates wasted time and resources by developing the product iteratively and incrementally. It’s the process by which start-ups create the minimum viable products they test.
An acceleration team should aim to only produce the documents that are useful and needed to manage the program, rather than writing “compliance only” documents which exist only to satisfy the interests of an outside stakeholder.
If there are requirements in policy that don’t make sense for your program, identify them and offer recommendations to tailor or waive that requirement. Be sure to include the information on the waiver authority organization, duty title, etc.
Understand the difference between a requirement that a program must have an XYZ strategy which complies with an organization’s template vs a requirement that a program capture and convey the core elements of their strategy to decision authorities and stakeholders. Ultimately the documentation is designed to ensure the program office has done sufficient critical thinking to execute the next phase of the program.
Develop an outline of the documentation the program office plans to compile, with the intended content in each document. Identify how this proposed set meets the documentation requirements. Present the proposed documentation outline with the decision authorities early in the process to solicit their approval. As some functional oversight organizations may resist tailoring their functional document, this may require the program’s leadership chain assuming they agree with the approach to engage on this is how we need to move forward for the program.
Program offices should be empowered to tailor documentation to their program’s environment. Based on type of acquisition, size, scope, complexity, and risk, the documents are there to help the program develop and execute sound strategies. The documentation is not intended to ensure compliance with some oversight organization’s standardized approach. Oversight organizations should develop and publish templates and guides for each major document to help the program offices apply the best practices from past programs and ensure critical areas are addressed.
A small, empowered, high-performing team is often able to deliver focused impact more quickly than larger teams or organizations made up of multiple teams. One of the primary reasons large teams or organizations don’t move quickly is the amount of formal coordination required before decisions can be made and actions taken. In a small team, members often work nearby and conduct regular brief check-ins to ensure each member is aware of the others’ efforts and challenges. This compact design enables the team to accomplish its purpose quickly and efficiently.
The number of communication lines between individuals multiplies when the team gets bigger, making it increasingly difficult to coordinate activities and sustain a high tempo. To facilitate control, large teams are broken into multiple smaller teams, and required coordination between them further increases. Over time, a greater proportion of the team’s resources are diverted to meetings, reports, emails, and other administrative activities to maintain alignment and coordination between the components. Thus, keep the team small to move fast.
Have a problem-solving mindset A key quality of a high-performing team is their ability to overcome obstacles. In a workplace, nothing is ever smooth-sailing. Problems come in many forms; it could be a delay from a supplier, technical breakdowns or an idea that didn’t translate in the real world.
1. Leaders support experimentation as a learning method
2. Workforce understands the methods, procedures, and purposes of experimentation
3. Workforce has access to resources e.g. a sandbox environment that replicates the operational environment and can be used for doing experiments without impacting operations
4. Workforce has access to mechanisms for sharing observations and lessons learned
5. Introduce experimentation principles and practices to team.
6. Quickly design and execute simple, informative experiments.
7. Craft a “campaign of experiments” to provide regular pace of learning and discovery.
8. Leverage existing communication reporting channels to inform leadership.
9. Pass along leadership guidance insights to your team so they understand the Big Picture
10. Start communications with the “why go fast” first — then articulate the “how.
11. Review policy on decentralized decision authority and publicize local application for your project.
12. As specifically as possible, identify decisions that can and should be delegated to lower levels.
13. When in doubt, delegate Assuming no explicit statutory or regulatory policy preventing the delegation
14. Establish shared expectations about decision-making authorities.
15. Continuously watch for instances where decision-making is slowed down by unnecessary involvement by higher-level authorities.
16. Encourage team members to sign up for additional training.
17. Arrange a group training session for the team.
18. Take a course yourself and share the lessons with the rest of the team.
19. Challenge a team member to research, develop, and deliver a course.
20. Who are the formal and informal leaders in the organization?
21. What messages are these leaders currently sending, and are these messages consistent with the desired culture?
22. What new messages should the leaders begin sending, in order to introduce the desired culture?
23. What measures are the leaders currently using to assess the organization’s performance, and how do these align with the desired culture?
24. What measures should the leaders focus on, in order to reinforce the desired culture?
25. What incentives are currently in place, and do they align with the desired culture?
26. What new incentives and rewards can be established to reinforce the desired culture?
27. Have leaders identified groups within the organization that already exhibit the desired culture?
28. What steps are leaders taking to hold up these groups as models or exemplars for others to emulate?
29. Don’t overly define the solution – Operational sponsors outline high level objectives
30. Empower “product owner” to set vision, shape requirements, and actively collaborate with users, acquirers, developers
31. Lower level requirements require flexibility to be responsive to changing operations, threats, risks, performance, and budgets
32. Requirements for current release should leverage only mature technologies and/or COTS solutions
33. Delivers capabilities to the users quickly
34. Enables iteration based on user behavior and feedback
35. Restrain system complexity, avoid over-engineered solutions.
36. Demonstrate and measure value accurately; rapidly iterate deliveries
37. Involve non-traditional vendors
38. Provides clarity and builds consensus about the problem to be solved.
39. Facilitates prioritization and focus, reduces wasted effort and mis-aligned, unproductive activities.
40. Identify an area that is overly complex or contains a large collection of unsorted ideas, designs, components, or facets.
41. Assess the outcome – briefly discuss whether the smaller set of remaining items is a better collection than what you started with.
42. A program in the early stages should plan to structure the delivery of systems or services of the full envisioned scope in multiple iterations.
43. Allow for iterative deliveries without having to meet the full set of performance requirements envisioned for the complete solution.
44. Understand the potential constraints and tradespace in determining iterative breakpoints based on major groupings of scope or a repeatable timeline e.g. annual deliveries
45. Identify dependencies with external programs and discuss with stakeholders the required functionality, interfaces/integration, and timelines.
46. Acquisition, contracting, engineering, and testing strategies should reflect the iterative structure to include the processes, resources, and decisions needed to field each release.
47. If establishing a new capability area, explore the opportunity to structure high level requirements via a new Portfolio
48. Setup a series of discussions with stakeholders from the operational/requirements organizations on managing requirements with greater agility.
49. Review existing contracts in your buying office to see if similar work is being done by the same contractor or subcontractor.
50. The best way to cure a sleepless night—yours and theirs–is to take action.
RSS Feed