Most programs that end up in trouble did not fail on a single bad day. They drifted, because nobody set clear limits at the start on what the program was, what done meant, who could decide what, and how new requests would be handled. Set Boundaries is built around fixing that. We set the boundaries first, make them visible to everyone, and then run the program inside them until it delivers.
This page describes how we work: the thinking behind the name, the six phases we take a program through, what you can expect in the first two weeks, the principles we hold ourselves to, and what we need from you. It is written for the people who carry the outcome: presidents and vice presidents, general managers, and directors of program management and engineering at aerospace, defense and maritime companies.
Why the company is called Set Boundaries
If clear boundaries for success are not set at the beginning of a program, made visible, and executed against, the program will not succeed. That is not a slogan. It is the pattern Holly Dekle, PMP, has seen across more than two decades of development, qualification and recovery work on engine controls, gearboxes, actuation, wing structures, naval systems and defense electronics. The programs that went well had clear edges. The programs that went badly had edges nobody could find.
The boundaries we mean are specific:
- Requirements: what the contract actually requires, as opposed to what someone asked for in a meeting
- Scope: the work that is in the program, and the work that is not
- Schedule: the major milestones, the payment milestones and the critical path between them
- Cost: the budget, and what the estimate at completion really is
- Authority: who decides what, and at what level
- Accountability: who owns each deliverable and each date
- Communication: who hears what, how often, and through which path
- Customer requests: how a new request is captured, assessed and either funded or declined
- Risk: the threats and opportunities that could move the outcome, and what is being done about them
- Definition of done: what completion looks like, in terms everyone can check
Three things hold those boundaries in place. The Project Charter establishes them. The integrated schedule makes them visible. The program office keeps the organization executing inside them. When circumstances change, and on a development program they always do, the tradeoffs are made visible so leadership decides, rather than the program quietly drifting to a new place nobody chose.
The six phases of the Set Boundaries method
Every engagement moves through the same six phases. The depth of each one is tailored to the program, the customer and the level of risk, but the order does not change.
1. Establish the Boundary
We start by talking with the people who know the program: the managers of each functional department and, just as important, the people actually performing the work. From those conversations Holly develops a Project Charter. In summary, it covers the requirements, the program vision and definition of success, the scope, the schedule with its major and payment milestones, the assumptions, the risks and opportunities, the budget, roles and responsibilities, and how communication and escalation will work. While the charter is being written, Holly builds the integrated schedule in Microsoft Project, so the team can see where the program is, where it is going, and what has to happen to get there.
2. Align the Team
Next we form an interdisciplinary project team, or IPT, with engineering, manufacturing, quality, supply chain, contracts and finance represented as the program needs. The point of the IPT is that everyone attacks the same problem with the same understanding of the requirements, the priorities, the schedule and who is responsible for what. Instead of everyone doing 30 percent of everything, the team knows exactly what has to happen each week to protect the critical path.
3. Execute the Plan
Set Boundaries Project Engineers execute to the plan Holly develops, working alongside your team rather than reporting on it from a distance. When a program is critical, that means short daily stand-ups and a weekly two-week look-ahead. Those meetings cover critical-path work, upcoming tasks, resource availability, roadblocks, risks, customer actions and any decisions leadership needs to make. People keep their autonomy over how they do their work. Our job is to make sure the destination, the priorities, the boundaries, the commitments and the escalation paths are clear.
4. Monitor and Intervene
Anything that threatens the critical path gets attention the same day. When an activity with no schedule slack starts to move the completion date or a major milestone, Holly calls a "Critical Path Red" discussion with the right stakeholders. The purpose is an informed leadership decision, not a status report. Leadership can provide help, change priorities, accept the impact, or pursue another solution, and it makes that choice knowing the cost and schedule consequences of each. Risks and opportunities are reviewed formally every month, and mitigation work is built into the schedule so it gets done rather than sitting on a register.
5. Communicate
We deliberately overcommunicate. Customers typically receive at least a weekly update. Senior leadership receives a formal program status at least monthly, and more often when the program is critical. The team always knows where the program stands, what has changed and what needs attention. On a recovery, communication with the customer may start almost daily until confidence returns.
6. Close or Transition
For a development program, recovery is complete when milestone payments have been achieved and production deliveries have started. At that point the decision about continued support is yours. Clients have generally chosen to extend support rather than have us leave, and where it makes sense and capacity allows, Set Boundaries can support the transition into production. Our guide to project closeout covers what a clean finish includes.
New program or recovery, the structure is the same. On a new program we build the structure needed for successful execution from day one. On a recovery we first find out what the team is actually working on compared with what the customer is contractually requiring, stop the work that does not belong, and then set the boundaries the program should have had from the start.
What the first two weeks look like
Clients usually call at one of two moments. The first is right after a major win, when the company knows the program is bigger than anything its current structure has handled and is not sure where to start. The second is later, when a program is missing commitments, the customer is frustrated, and the business relationship is at risk. The first two weeks look similar in both cases.
- Listen first. Holly meets functional managers and the engineers, planners and technicians doing the work. The people closest to the work usually know where the real constraints are.
- Read the contract against the work. Requirements, statements of work, milestone and payment terms are compared with what the team is actually doing. On a recovery this is where uncontrolled or out-of-scope work usually shows up. Our requirements-to-work assessment describes this step in more depth.
- Draft the charter. The boundaries are written down, reviewed with stakeholders and agreed.
- Build the schedule. The integrated schedule is built with real input from the people doing the work, so the critical path reflects reality rather than hope.
- Sign and start. Typically within one to two weeks you have a signed Project Charter and an executable plan, and the team starts working to it.
That timing is typical rather than fixed. A large program with many stakeholders can take a little longer to align, and a recovery with deep technical issues may need more time to establish what remains. What does not change is that the program has a written set of boundaries and a plan built from them before anyone is asked to work harder.
The three questions everyone should be able to answer
On a program run inside clear boundaries, anyone on the team, from a design engineer to the general manager, should be able to answer three questions at any time:
- Where are we?
- Where are we going?
- What has to happen next to get there?
When those answers differ depending on who you ask, the program has lost its boundaries. Most of what we do, from the charter to the schedule to the weekly look-ahead, exists to make those three answers the same for everyone, including the customer. The goal is to eliminate ambiguity, because ambiguity is where schedule and money disappear.
Three principles behind every engagement
We treat every dollar as though it were our own
Program money is finite, and most programs spend it faster than they planned. We look for the option that protects the budget, not only the one that is easiest to approve. On one program a new test rig was planned that turned out to be very similar to equipment from a product line that had recently completed production. Evaluating the return on modifying the existing capability, rather than building new, saved money, schedule and manufacturing capacity.
We know how to sell time
Sometimes the constraint is not money but the calendar. On one program the team needed substantial qualification documentation and did not have the people to produce it for several months. Rather than hire expensive contractors, Holly recognized that the customer also needed a software change, and built a strategy that addressed the customer's immediate concern first while moving qualification testing several months later. The customer got something it needed, and the team gained the time it needed to prepare properly.
We create strategy among competing priorities
When everything is a priority, nothing is. We build visual, integrated schedules with real input from the people doing the work, identify the critical path, and focus effort on the activities that decide the outcome. The practical instruction to a team is simple: stop doing 30 percent of everything and start finishing the things that matter.
How Holly runs a program
Holly's style is direct, structured, technically engaged, calm and accountable. It helps to know what that looks like in practice before an engagement starts.
- Direct. She says what she sees. For organizations used to reading between the lines, that can take a week or two to get used to, and then most teams find it a relief.
- Structured, but tailored. The structure fits the program, the stakeholders, the customer and the level of risk. A small development program does not get the overhead of a large defense contract.
- Technically engaged. Holly is an engineer. She can understand the technical issue, challenge assumptions, help develop practical alternatives and weigh them against schedule, budget, risk and requirements.
- Calm. When something goes wrong there is no panic. It is a "plot twist": identify what changed, determine the impact, develop options and move forward.
- Autonomy on how, clarity on what and when. She does not micromanage how engineers work. She sets what needs to happen, when, why it matters and where the boundaries are, and then trusts people to use their expertise.
- Conflict addressed directly. Two people with an issue talk to each other before it is escalated. If Holly has a concern about someone's performance, she talks to that person before their manager, and she expects the same courtesy in return.
Former team members have said they valued knowing what was expected, having realistic plans, not having everything treated as an emergency, being able to take vacation without guilt, and being protected from uncontrolled work while everyone was still held accountable. In Holly's words: "My job is not to make everyone's decisions. My job is to create an environment where good people can execute successfully."
What we need from a client
The method works when three conditions are in place. We ask for them at the start, because without them no program office can deliver.
- Appropriate decision-making autonomy to run the program day to day, with clear escalation to leadership for the decisions that belong there
- An interdisciplinary team, the IPT, with the functions the program needs and people who can commit time to it
- Access to the information and systems the program depends on: contracts, requirements, engineering data, schedules, cost and supplier information
We prefer to work inside your own computer environment rather than ours. That keeps program information under your control, means you always have access to status and data, and reduces cybersecurity risk, which matters on defense programs handling controlled information. If a resource you would like to provide is not available, we explain the tradeoff, develop alternatives, and show leadership the cost, schedule, performance and risk consequences of each path, so the decision is informed.
There is one boundary we do not compromise: professional respect. Disagreement is healthy and pressure comes with the work. Disrespectful or abusive behavior, toward our people or yours, is not acceptable.
How an engagement ends
Our goal is not permanent dependence. When Set Boundaries steps back, one of two things is true. Either the program has delivered: commitments are being met, milestone payments have been achieved, production deliveries have started and the customer is satisfied. Or your organization has a repeatable program office process and a culture that knows how to run it, so the next program starts correctly without us. Often it is both.
On a recovery, the objective is that within a few months the organization is consistently delivering on its commitments and the customer's confidence has been restored. Set Boundaries is the company you call when a program has to be recovered or delivered, and the way we measure that is whether the program keeps delivering after we have stepped back.
Where to go from here
If you have just won a program and want it set up correctly, or you have a program that is missing commitments, the fastest way to find out whether this method fits is a conversation with Holly about your program, your customer and your constraints. You can schedule a call directly.
Holly is able to quickly formulate and execute detailed project plans transforming chaotic programs into predictable successes. Key to Holly's triumphs is her deep project management knowledge, work ethic and clear communication style.
Holly knew how to drive her team to deliver results within a very aggressive timeline and managed change very effectively. When you work with Holly you always know the status of your project and know what will be delivered and when.
Holly was always proactive in managing the team and ensuring that we stay on schedule and meet customer needs. Holly also is good to ensure we follow process and always incorporated any lessons learned from previous programs into her own.
Related guides
- Program management office support for aerospace and defense programs
- Writing a project charter that sets real boundaries
- Program recovery for aerospace and defense programs
- Requirements-to-work assessment
- Risk and opportunity management
- Case studies
References
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide)
- Project Management Institute, Project Management Professional (PMP) certification
- SAE International, AS9100, Quality Management Systems: Requirements for Aviation, Space, and Defense Organizations
- SAE International and EIA, EIA-748, Earned Value Management Systems
Questions
Common questions
What does Set Boundaries actually mean by a boundary?
A boundary is a clear, written limit that tells the team what the program is and is not. We set ten of them: requirements, scope, schedule, cost, authority, accountability, communication, customer requests, risk and the definition of done. The Project Charter establishes them, the integrated schedule makes them visible, and the program office keeps everyone working inside them. When something has to change, the tradeoff is shown to leadership so the decision is deliberate rather than the program simply drifting.
How quickly will we see a plan after you start?
Typically within one to two weeks you have a signed Project Charter and an executable plan built in Microsoft Project. That period is spent listening to functional managers and the people doing the work, comparing the contract with what the team is actually doing, and building the schedule with their input. A very large program or a recovery with deep technical issues can take a little longer, but the team does not wait weeks to know what matters.
What is a Critical Path Red discussion?
It is the conversation Holly starts when an activity with no schedule slack begins to move the completion date or a major milestone. The right stakeholders are brought together quickly, the impact is laid out, and leadership makes an informed decision: provide help, change priorities, accept the impact, or pursue another solution. The point is that critical-path problems reach decision makers while there are still options, not weeks later in a monthly report.
Will your team take over how our engineers do their work?
No. Holly sets what needs to happen, when, why it matters and where the boundaries are, and then gives your people autonomy to use their expertise on how. Set Boundaries Project Engineers work alongside your team to keep the plan moving, clear roadblocks and track commitments. Teams we have worked with have said they valued realistic plans, clear expectations and protection from uncontrolled work, rather than feeling supervised.
Why do you want to work inside our systems rather than your own?
Keeping the work inside your computer environment means program information stays under your control, you always have access to status and data, and cybersecurity risk is lower than moving files between companies. On defense programs that handle controlled technical data this matters a great deal. It also means the schedules, registers and reports we build remain yours, so the process keeps working after the engagement ends.
How do we know when the engagement is finished?
We agree the finish line at the start. For a development or recovery program it is usually reached when commitments are being delivered, milestone payments have been achieved and production deliveries have started. Alternatively, the engagement ends when your organization has a repeatable program office process it can run on its own. Clients have often chosen to extend support after that point, but the decision is always yours.
Have a question that is not here? Ask Holly on a short call
