This is the latest in a series of articles on #noprojects; examining how organisations can deliver continuous change without project structures. If you haven’t already, you should read the first in this series.
We will start this article by looking at the costs of running a project vs a continuous change model to help you understand the financial benefits of #noprojects. We will then get practical and dive deep into a #noprojects implementation and give you a framework to structure work as activities around defined outcomes. You can jump straight to part 2 if you are already convinced of the value of #noprojects.
The cost of projects
Projects are, by definition, a layer of management, governance, and supporting activities on top of an agreed sequence of work. As such, by definition again, projects introduce additional costs into the work process. We will start by looking at the three O’s of cost that differ between continuous changes vs. a project; Overheads, Overruns and Opportunity costs.
A quick definition: Overheads are the direct costs borne from running a project. These are relatively small, but the easiest to quantify and recover. Overruns are potential costs caused in rectifying planning, estimation issues or overall project failure. Depending on the risk profile of the project and the maturity of the organisation’s estimation process, these costs can range from very small to very large. Lastly, an opportunity cost is the forgone revenue expected between project initiation and deployment. The longer a project runs without deploying a change, the larger the opportunity costs.
Overheads
Let’s start by agreeing that the overhead costs relating to the creation of value and delivery of outcomes will remain relatively constant regardless of the approach taken. For example, costs unaffected by #noprojects include staff costs & associated benefits, development activities (including testing and documentation), development, test, staging and production environments, continuous integration, continuous delivery, license fees, travel expenses, and office space for the team. In organisations with poor development practices, these costs may actually increase in the short term as a consequence of creating a mature development environment.
However, by changing the delivery approach, #noprojects can negate many of the costs related to managing a project. These include:
- Project managers: this is fairly obvious, as these staff (or contractors) are no longer required to spend time planning and tracking the project.
- Project-specific events: kickoff meetings, project planning, and project closure.
- Project-specific deliverables: milestone documents, sign-off packs, project risk registers, communication plans, schedules and Gantt charts, work plans, etc.
- Project administration: this may include staff hired to undertake project accounting or secretariat functions.
- Project management office (PMO): this may include organisations PMO’s or smaller PMO’s created at a programme level.
- A reduction in additional contractors and/or staff overtime: because of the emphasis on schedule, many projects request overtime or hire contractors to meet estimated timelines.
I’ve known projects to spend more than 6 months planning, chasing signatures and getting approvals for a 2 month project. In these extreme cases, project overheads can exceed the cost of delivery.
I’ll leave it to you to assess the potential overall cost savings for your organisation. However, to be effective, you need to be able to distinguish between project overheads and common business overheads.
Overruns and Failure
I think it’s safe to say that projects fail with disturbing regularity; whether by failing to deliver a solution that meets the business expectations, releasing later than planned or costing more than initially budgeted. The solution isn’t better planning. Projects already spend significant effort in the early stages to plan and estimate the scale of effort and yet, according to the HBR, the average cost overrun was 27%, with one in six IT projects having an average cost overrun of 200% and a schedule overrun of 70%.
We examined 1,471 projects, comparing their budgets and estimated performance benefits with the actual costs and results. They ran the gamut from enterprise resource planning to management information and customer relationship management systems. Most … incurred high expenses—the average cost was $167 million, the largest $33 billion—and many were expected to take several years. …
When we broke down the projects’ cost overruns, what we found surprised us. The average overrun was 27%—but that figure masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.
These risks are compounded when there is undue pressure to align the project budget to a business expectation, leading to “fuzzy estimates” with little bearing on reality. Fundamentally, this leads to the question “why bother?”
These statistics are nothing new, you’ve probably seen some of them around. But that is exactly my point. IT project failure has become so commonplace that it is now accepted and usually expected.
For example:
- A Geneca survey of 600 executives show that 75% of business and IT executives anticipate their software projects will fail and are “doomed right from the start.”
- The 2012 CHAOS survey shows that only 39% of all projects succeeded (delivered on time, on budget, with required features and functions); 43% were challenged (late, over budget, and/or with less than the required features and functions); and 18% failed (cancelled prior to completion or delivered and never used).
- EU figures looking at 214 technology projects from 1998 to 2005 showed that only 1-in-8 technology projects met their time, budget and quality objectives, with nearly 25% of all projects not completing at all. Total technology project overruns just from 2004 totalled €142bn.
- A 2010 KPMG survey showed that 70% of organizations had one or more failed projects during the previous 12 months.
- And a 2008 survey by Logica showed that 35% of organisations abandoned a major project in the last 3 years.
But what about the return on investment; even when a project overruns, can it still be considered a success? Unfortunately not in many cases. Based on findings from more than 5,400 IT projects, on average, large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted. “We also found that the longer a project is scheduled to last, the more likely it is that it will run over time and budget, with every additional year spent on the project increasing cost overruns by 15 percent”.
These statistics demonstrate a fundamental flaw in the approach taken to IT project management regardless of size, technology, vendor, approach or processes used.
#noprojects provides a better and less risky approach to delivery by removing the common factor in all of these failures, the project itself. This is not to say that there are no failures in a #noprojects approach. However, because of the discrete nature of #noprojects activities, technical failure is self-contained, easily identified and generally recoverable. Failure relating to project process, project governance, stakeholder buy-in, and scope management is, by definition, no longer relevant.
Opportunity costs
Opportunity costs can be the hardest to quantify, but can be the largest single cost to an organisation running a project. As mentioned earlier, I have seen organisations take up to 6 months of planning and approvals just to begin a short, 2 month, project. That’s 6 months of foregone revenue or productivity gains. With a #noprojects approach, you are able to bring value to market sooner than initiating a project.
Once again we can turn to reports and research to show actual examples of this.
According to a report in 2008 by the Treasury Inspector General for Tax Administration, the (US) Federal Government lost approximately $894 million in fraudulent refunds during 2006 because the system was not operational.
And this is just the forgone revenue. It doesn’t include the direct costs borne by the organisation for workarounds, interest on the foregone revenue, or revenue from any re-investment.
When looking at other opportunity costs you would also consider;
- lost market share,
- flow-on costs to customers,
- continuing maintenance costs for legacy systems, and
- productivity loss (or more accurately unrealised productivity gain).
In the majority of cases, the overhead at the start of a project, and thus the associated opportunity costs, are driven by project initiation approval and funding processes. And as any process is only as fast as its slowest point, any delays or bottlenecks have a flow-on impact to the rest of the project.
I want to finish with a quote from an article by Johanna Rothman which I feel encapsulates this idea perfectly.
Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.
A focus on value not effort
Let’s start you with some basic #noprojects terminology. An outcome is a meaningful, and fundamental, change in the status quo as a result of a series of related changes. An activity is any discrete work that is undertaken as part of a change.
For teams to be successful when undertaking complex work, they need to be structured around delivering outcomes. I call this a Value Delivery Team. This is a different approach for many organisations, as teams are traditionally structured around functional capabilities (e.g. Finance, HR, sales, or IT). As outcomes may require the skills from multiple functional areas, These cross-functional teams benefit the organisation by improving coordination, simplifying communication & accountability, and sharing expertise to solve problems. This is similar to a team formed in a matrix organisation, however a Value Delivery Team (or division) should be permanent and report to a single, accountable, line manager.
An organisation will obviously be working on multiple outcomes simultaneously and each of these will be assigned to one or more permanent or temporary teams as required. In turn, each team is accountable for planning and delivering the ongoing activities required to achieve the outcome assigned to them. It is important to ensure outcomes do not contradict each other or lead to unintended consequences.
Organisations need a way to manage work without resorting to projects. That’s where activity management and the activity canvas come in. The activities delivered by each dedicated Value Delivery Team to achieve an outcome exist on a continuum; small to large effort against low to high value. Your status quo (or do nothing) sits at the bottom left. This is managed on the activity canvas below.
The Activity Canvas
The Activity Canvas
Activities in the ‘Do’ quadrant are relatively easy to perform and make measurable progress towards the outcome. Those in the ‘Defer’ quadrant are important, but complex, and need to be planned appropriately. The ‘Limit’ quadrant, usually your hygiene processes, should still be undertaken but only when needed or as time permits. At the bottom right is the ‘Avoid’ quadrant, and it would be rare for you to undertake any activities here.
Activities that you know are coming up, but you’re not ready to plan yet can be placed underneath the canvas in the ‘Upcoming’ section. This allows you to keep track of anticipated work without overloading the board.
This begs the question: why would you bother adding anything into the avoid quadrant? In short, because this is an active management tool, and each activity will be continuously reassessed and may change quadrant (e.g. from ‘Avoid’ to ‘Do’) as circumstances change.
A note on value: in most cases value is highly subjective and hard to quantify. This is expected, and part of the risk of doing business. After all, if we could accurately predict the return on every investment, the market would be a lot more predictable. When ranking activities on the value axis, each activity is compared against its peers - is x more or less valuable than y (in the context of the outcome)? If you can quantify an activity, (e.g., revenue generated, cost of delay, users requests, etc.) then definitely do so, but do so, but don’t rely on this in all cases. An additional benefit from the activity canvas is that it encourages teams to reduce the overall size of their work, which naturally leads to smaller batch sizes, faster deployment and evidence-based ROI decisions.
The actual activity canvas used by a marketing team to launch a new product
Each activity on the canvas should be independent. That is, it could be removed from the canvas with no impact to any other activity. Obviously, this is not always possible, but it should be a key consideration when designing activities. If you’re finding that none of your activities are independent, try creating canvases at multiple levels. One canvas for master activities and separate canvases for sub-activities within each master activity.
By defining independent activities, each of which deliver value within the context of the outcome, a pattern emerges. Our focus changes from ‘Prioritisation’ (high, medium, low) to ‘Order’ (1, 2, 3, 4, 5). That is, we no longer care what activities are high priority, we care about which is first. A natural side-effect of this is the overall reduction of work-in-progress, which in turn increases the throughput and productivity of our team.
Based on this, we can actually draw a path between our activities; starting from the first activity to the final activity. All else being equal, the standard path should look something like this:
The Natural Flow of Activities - from upper left to lower right
The flow of activities from the above example
But what if all else isn’t equal. Activities with fixed due dates or dependent activities will naturally impact the order of work. Dependent activities should be rare if you’re following the principle of independence. Where it exists you can redraw the path based on the new order. This will also help you identify and streamline common dependencies.
Activities with a fixed due date are anomalous, but expected. These may jump to the head of the queue regardless of which quadrant they are in (although activities in the ‘Avoid’ quadrant should still be avoided where possible).
The terms and conditions activity has a fixed date bringing it to the top of the queue
There is another benefit to this approach; by actively managing your activities you can identify structural problems with your Value Delivery Team. Where activities are appearing on the board (especially in the ‘Do’ and ‘Defer’ quadrants) faster than they are being completed, it is likely that you do not have the right number, or mix, of staff. Use this opportunity to run a retrospective to analyse the root cause of the issues and either increase your team’s capacity or identify a different approach.
If you can effectively manage this flow of activities, there is no need to create a project to deliver change.
About the Author
Evan Leybourn pioneered the field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. He keeps busy as a business leader, consultant, non-executive director, conference speaker, internationally published author and father. Evan has a passion for building effective and productive organisations, filled with actively engaged and committed people. Only through this, can organisations flourish. His experience while holding senior leadership and board positions in both private industry and government has driven his work in business agility and he regularly speaks on these topics at local and international industry conferences. As well as writing "Directing the Agile Organisation", Evan currently works for IBM in Singapore to help them become a leading agile organisation. As always, all thoughts, ideas and comments are his own and do not represent his clients or employer.
