Most organizations and leaders have succumbed to the sunk cost fallacy — sticking with a project or team member based on the time and money already invested, even though there is no sign of a turnaround. Being aware of this phenomenon is the first step in making sure ego does not trump rational decision-making.
Many business leaders are unacquainted with the wealth of knowledge about how software projects behave. No surprise, they are unable to explain why these projects fail repeatedly, much less do something about it. Here are five fundamental “laws” of software development that all executives (and teams) should understand and follow.
Project costs receive serious scrutiny from executives and stakeholders who use ROI and other financial metrics to judge organizational performance. Here is a checklist of questions to help project leaders and their teams determine the best available options for responding to project cost risks and issues that may arise.
A common human trait called “optimism bias” leads many project leaders to build unrealistic schedules and underestimate budgets. Buffers, retrospectives and peer reviews are some of the fundamental steps that can help you balance your optimism and produce better estimates.
How they affect the project can vary from company to company, project manager to project manager and project to project, but each of these seven factors — spanning budgets and resources to stakeholders and requirements — will have severe negative implications for the success of any project.
An Agile approach to budgeting recognizes the need for frequent course correction by outcome owners who can respond to the business when they have autonomy. It favors accountability over expenditure tracking; it's using road intersections with roundabouts (cooperation) rather than traffic lights (compliance).
When organizations fail to achieve strategic goals, they often fail first to prioritize and align the necessary resources. In order to execute complex initiatives, leaders must continuously evaluate teams across a range of technical and relational skills, and then empower, support and invest in people who can get it done.
Estimates are far from perfect, but the business side is always going to want some sense of “how long, how much?” — even on Agile projects. Technical teams may have the most relevant knowledge to answer, but they don’t always have the willingness or tools. Here, Rex Madden of Stride NYC frames the issue and discusses options. [30 min.]
Value-driven projects differ from plan-driven projects in significant ways, including how teams are formed, how funding is obtained, how scope is determined and how solutions are achieved. They seek valuable rather than predictable results. Here’s a roadmap to making the switch.
Top agile organizations favor a product-centric model of execution over a project-centric model. They chase value instead of predictability. Let’s look at what’s wrong with plan-driven projects, and why it’s better to organize your efforts along business capabilities, supporting capability teams instead of project teams.