Developing and fielding software solutions is hard.  Turning a set of requirements into a viable and useful solution often feels like embarking on a voyage of discovery.  Along the way, we deal with previously known and unknown constraints on what the solution can be, what it can do, and how well it can do it. 

Many managers and technical implementers fail to see the difference between constraints and impediments.  As a result, we deal with issues we could have planned for ahead of time only after they become impediments to progress.  Also, an unwillingness to remain open to alternative ways of fulfilling requirements locks us into “all or nothing” thinking that causes us to fight against constraints instead of leveraging them to better define solutions.

Constraints vs. Impediments

For the purposes of this article, a constraint is anything that restricts the implementation and behavior of a solution.  Constraints shape the solution by placing limits or imposing requirements on how we develop, deploy, support, and use the solution.  Impediments, on the other hand, are occurrences or circumstances that prevent us from making progress towards developing, deploying, and supporting the solution.  We are much more able to plan for constraints than for impediments.  Ignoring or not adequately managing constraints leads to impediments, sometimes project wrecking ones.

I categorize constraints as fundamental and organizational. Before discussing how to manage these constraints, let’s understand what they are.

The Fundamental Constraints

The four fundamental constraints on all solutions are solution requirements and the constraints of the Iron Triangle: cost, schedule, and scope. 

Solution Requirements

If we do a good job of defining needs, without jumping to specify solutions, we end up with requirements.  Requirements are the first constraint on what a solution will offer and how it will perform.  Solution capabilities or features are functional requirements.  How well the solution performs or behaves is characterized by non-functional requirements (NFRs).  Requirements start to narrow the infinite range of approaches we could take towards solving problems or addressing needs.

For example, a small town library may be fine using a card catalog to track its holdings.  Due to the relatively small amount of content offered and number of library patrons, manual tracking via cards and lists works both from a functional perspective (tracking books/media) and from the perspectives of cost and simplicity (NFRs).  The same solution would be woefully inadequate at a large university or the Library of Congress.  For large libraries, solutions must be highly automated and digitized to be viable and cost effective.  The NFRs associated with managing the holdings of a large library filter out the option of using manually-intensive solutions.

Cost, Schedule, and Scope

The narrowing of solution approaches continues as we account for the constraints of the Iron Triangle.  Requirements inform analysis of project scope.  The more requirements we address, the larger the solution becomes (greater scope).  The number of requirements, and their relative complexity, drive schedule and cost.  Smaller budgets and/or tighter schedules typically drive down the amount of scope development teams can deliver.  Not aligning scope to budget and schedule constraints risks degrading quality.

NFRs drive the level of quality necessary for the solution to be viable and effective.  The Iron Triangle constrains quality indirectly.  We can’t buy quality as a system feature delivered by a certain time.  Instead, we build quality into the solution by ensuring we build the right things in the right ways.

Organizational Constraints on Solution Development

Organizations that develop and/or sponsor development, fielding, and support of software solutions impose constraints on those solutions.  These organizational constraints tend to reinforce the fundamental constraints discussed in the previous section.  I categorize organizational constraints as Enterprise Governance, Programmatic, and Implementation constraints.  These categories align with organizational structures typically found in large organizations.  In large organizations, most software systems development supports systems integration as opposed to product development.

Enterprise Governance Constraints

MITRE defines enterprise governance as:

The structure and relationships that control, direct, or regulate the performance of an enterprise [and its] projects, portfolios, infrastructure, and processes

MITRE. Systems Engineering Guide. https://www.mitre.org/publications/systems-engineering-guide/enterprise-engineering/enterprise-governance. Accessed 5/21/2022

Constraints at the enterprise level inform constraints at the program and project levels of the organization.  Table 1 below lists the most common examples:

Programmatic Constraints

Along with ensuring implementation of enterprise governance constraints, program management offices (PMOs) also impose their own constraints on the development, fielding, and support of software solutions.  PMOs focus primarily on the day-to-day management of Iron Triangle constraints across development projects and sustainment efforts as well as the associated contractual mechanisms that enforce those constraints.

Implementation Constraints

Individual projects add requirements, design specifications, and technical implementation details to the full weight of constraints flowing down from enterprise and program organizational levels.  Considerations directly tied to development of solution capabilities further constrain implementation choices.

This applies to both what development teams develop and how.  From a technical implementation perspective, the following are examples of choices often constrained by policies and procedures from higher organizational levels:

• Forms of application or system architecture (e.g., service-oriented, monolithic, client-server)
• Which technologies development teams employ
• How development teams implement business / mission rules

The same applies for how development teams work.  For example:

• Contractual requirements may specify that teams must work within an Agile framework such as Scrum or SAFe
• Developers may be required to use enterprise CM, Agile, and DevOps tooling and deployment environments provided and maintained by the organization

Managing Software Solution Constraints

People often see constraints as inherently bad.  They see them as frustrating inconveniences or problems that hamper solutions development.  Instead, we should see constraints as criteria that help narrow design and implementation choices to those most likely to foster solution success.  Delivering on requirements while aligning solutions to enterprise, programmatic, and implementation constraints achieves fit.  By fit I mean that a solution performs its work, at expected levels of performance and quality, in harmony with organizational, contractual, technological, and procedural realities.

Figure 3 and Table 2 below outline a process for managing software solution constraints.

Implementing Workarounds

A workaround is a way of accomplishing the same work or achieving the same results when a preferred approach would violate constraints.  Workarounds allow us to implement solutions that would otherwise not align with constraints.  There are two ways of working around constraints that can’t be waived or changed:

1. Technological Workarounds: Implement new or use existing technologies, services, systems, applications, etc. to address constraints.  Chosen approaches become part of the solution’s implementation and architecture.
2. Procedural Workarounds:  Implement auxiliary processes or procedures.  For example, manual processes may fill requirements gaps not addressed by a solution.

Managing Project Scope

An agile way of managing constraints is through managing project scope.  For example, a constraint keeps us from implementing a feature in its entirety.  The constraint can’t be waived or changed away.  We could break up the feature to only implement functionality that does not break the constraint while we look for alternatives.  We can choose to deal with the constraint at a later time while working within the constraint.  A limited implementation of the feature may turn out to be good enough.

Conclusion

Traditional project management has conditioned us to think in terms of “getting it all done.”  In other words, implementing solutions according to predictive plans and designs that can’t be changed.  This is unrealistic because, try as we might, we will not identify all of the constraints we will encounter before we start. 

We have to do our best in identifying constraints as soon as possible so we can address them before they become impediments.  At the same time, we need the agility to deal with unanticipated constraints.  We achieve this balance by not treating constraints as obstacles but as influences that help shape what solutions will become.

---

[2] Association for Project Management. https://www.apm.org.uk/resources/what-is-project-management/what-is-portfolio-management/#:~:text=Portfolio%20management%20is%20the%20selection,while%20optimising%20return%20on%20investment. Accessed 5/21/2022

[3] Bennett Conlin. https://www.businessnewsdaily.com/4813-contract-management.html. Accessed 5/22/2022

[4] CIO.com. https://www.cio.com/article/222421/what-is-enterprise-architecture-a-framework-for-transformation.html. Accessed 5/21/2022

[5] https://en.wikipedia.org/wiki/Configuration_management. Accessed 5/21/2022