An Organization Must Assure it Correctly Applies Constraints to Projects
An organization might believe that it needs certain constraints, because it believes incorrectly that they further certain goals. Those restrictions are not necessary, and they present a different problem for institutions. Companies need to assure they are not misapplying limitations.
A boundary acts a signal. For example, a due date tells a business and the people on a project that an undesirable outcome occurs, if an undertaking surpasses it. Budgets and objectives communicate similar information but in different ways. Each constraint is a tool for relaying a particular notion. An organization should only deploy that technique, when it wants to deliver a specific message.
If an institution has a different goal, then it should use another approach. For example, a company might want to monitor the progress of its projects and their expenditures. It might use a due date or a budget to achieve those goals. Yet, those approaches are not designed as tracking tools. They can be used to watch an undertaking’s movement, but they are, at best, a crude means to do so. For example, advancement towards an arbitrary deadline might not have any real relationship to the actual direction of an endeavor. That venture’s evolution is more accurately tracked by an organization, through a different tool. An institution should not use constraints for goals, other than conveying signals.
If a company sends messages unintentionally, then it misaligns incentives. Its employees follow stimuli whether they are aware of them or not. If a business sets a budget, a due date, or an objective, it sends its people specific memos. Those individuals might not consciously change their actions, but they will still alter their behavior. Their organization might not want them to behave in that manner. Yet, sweeteners will push them to do so. When an institution delivers messages unintentionally, it distorts incentives.
Those mangled stimuli can misrepresent the picture of a company’s issues. For example, a business senses that it has a significant problem. It notices that it regularly misses its deadlines and surpasses its budgets. It concludes those failures are the root cause of its difficulties. Yet, that organization frequently sets arbitrary timetables and allocations for its projects. It experiences no harm for not meeting those requirements. Yet, those constraints create an image that it is. That institution’s actual issue is obscured by misleading messages.
Curated Content and Authors
Mike Cohn discusses approaches to handling the effect of vacation and time off, on velocity.
Taylor Armerding talks about the risks supply chains pose to an organization's security.
DataKitchen meditates on the push and pull between a need for shared sense of truth and need to innovate.
Chris Crowley describes the data flow for hunting for threats, in security operations.
Bob Reselman discusses DevSecOps in a mainframe-driven enterprise.
We wrote that describes how an organization can identify underlying problems in it software development operations.
We penned a piece that describes how conclusions form the logical bedrock of a strategy.
Adam Shostack is an expert on threat modeling.
Endnotes
This article does not answer every question regarding constraints. Those topics are addressed further, in future issues and blog entries. To read them, subscribe to this to newsletter and read the Software Construction Journal. To learn more about application construction, follow ExperTech Insights on Twitter.