#noprojects - A Culture of Continuous Value
No matter how many projects we run, project failure rates remain consistent. It’s time for a change in perspective. Try #noprojects. Download the free book.
Or why projects must die *
I want to be controversial for a moment and propose an end to IT projects, project management & project managers. I propose that the entire project process is flawed from the start for one simple reason. If you need to run a project, you've already failed.
By definition, an IT project is a temporary structure to govern and deliver a complex change (such as a new product or platform) into an organisation. However, to be truly competitive, an organisation needs to be able to deliver a continuous stream of change. Managed properly, this negates the need for a project and the associated cost overheads.
The key word here is continuous. While there may be fluctuations in demand and effort, there should be a continuous allocation of resources to maintain, enhance and support most IT systems. If done properly there should never be a need to run an "upgrade" project, a "version 2" project, a “maintenance” project, a “greenfields” project, or a "redevelopment" project. Even when creating something for the first time, a revolutionary change rather than an evolutionary change, a project structure explicitly defines an end; a point when the project or product will be done. Rather, it should be understood that (until the end of its life), every product will continuously change and improve. You may bring in additional staff early on, but with good resource management and capacity planning this can be managed across different demands.
This is fundamentally what #noprojects is. The approach, structure, tactics and techniques available to successfully deliver continuous change. At its core, #noprojects predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies. These concepts are explored further in this and following articles.
Why #noprojects
Projects address a static need
The intent of any project is to address an identified need, whether internally or for a customer. However, customer needs change over time and will always outpace, and outlive, the ability for a project to deliver. Even the most comprehensive project leaves residual need which, over time, continues to grow and will lead to follow-on projects. By continuously delivering change, customer demands can be continuously prioritised and delivered.
For this, an organisation should be focused on outcomes rather than outputs and measured by its value to the organisation. Fundamentally, teams work on activities that create a change within the context of an outcome. Within #noprojects, this is managed through the Activity Canvas and Outcome Profile and will be further detailed in the subsequent articles; “Activities Not Projects” and “Outcomes: The Value of Change”.
Projects are expensive
There is an explicit, and implicit, cost to running a project above the change itself; Project Managers, coordinators, meetings, not to mention forgone opportunity costs. These can be quite significant and lead to major costs to an organisation. By definition, continuous change processes do not require as many overheads and should have implicit governance built in. This will be further detailed in a later article; “The Costs of Doing Projects” - and will examine the three O’s of cost that differ between continuous changes vs. a project; Overheads, Overruns and Opportunity costs.
Estimates can be useful - but not accurate
Every project manager has been asked the question “When will this be done?”. The sad truth is that estimates (such as the duration of a project) are extremely hard to get accurate, and even harder to get right. A small change is, by its nature, easily estimated and prioritised; reducing the risk of misleading or inaccurate formal estimates.
Projects fail
As a consequence of the cost and difficulty in running projects, the failure rate of IT projects is extraordinarily high. By any criteria, an IT project has a significant risk of overrunning time, cost or scope, with the associated financial, opportunity and reputational cost. In many cases, this is not a failure of the project, but rather a failure of estimation. In reality, an activity takes as long as it takes; but longer than we want. This will also be explored further in “The Cost of Doing Projects”.
They say that the definition of insanity is to do the same thing and expect a different result. So why do we keep running projects when, in contrast, multiple small changes are easily managed and thus the risk, and associated cost, of failure is significantly reduced. Of course, there are other benefits to incremental changes, which is why agile projects encourage this approach as well.
Retention of subject matter expertise
There is a loss of knowledge when a project team is disbanded. Even more so where that team is made up of contractors or vendor resources. This also leads to additional costs for knowledge transfer to Business-as-usual staff as well as recruitment and retraining when the inevitable follow-on projects commence. This is implicit in the temporary nature of a project. A continuous change model, especially when combined with dedicated Value Delivery Teams, resolves this by ensuring continuity of staff.
How to start #noprojects
One of the primary reasons organisations use projects is to predict and control budgets and financial spend. Putting aside the aforementioned financial overruns and unpredictability of projects, continuous change is highly predictable with a linear spend curve that can scale on demand. By dynamically planning, prioritising and monitoring activities against outcomes, teams can manage their budgets and deliver the highest value activities first. Activity tracking, and the Activity Canvas will be explored further in the next article.
Leadership of Value Delivery Teams
#noprojects is as much a cultural change as it is a process change. As much managers need to lead this approach and support their teams in identifying their natural rhythm, or cadence, of work. Leaders of Value Delivery Teams are fundamentally accountable for the real time planning of activities. Some activities, traditionally under the domain of project managers, remain - such as stakeholder engagement, expectations management, risk management and so on. Project coordination & related monitoring & reporting activities obviously are no longer required as they are either implicit in the process or obsolete.
Right-sizing your work
This whole process only works if your changes are small, ideally less than 1-2 days of work. Activities that require larger changes need to be decomposed into small independent changes. It should be noted here that, in addition to quality control and automation, each change must have a clear Definition of Done (DoD) that includes activities such as user documentation updates. This will be explored further in “Organisational Outcomes vs Team Outcomes”
We’re going to get a little technical here. #noprojects works best when you have systems in place to streamline the continuous change process. For example:
Continuous Delivery / Rollback
Continuous Delivery (CD) is nothing new; the ability to deploy incremental change has been around for a while. Fundamentally, it is a design & development technique to automate and improve the process of software delivery. Consisting of a variety of techniques such as automated testing, continuous integration and continuous deployment, CD allows Value Delivery Teams to rapidly and easily package and deploy changes to test and production environments. Along with automated rollback, this speeds up the deployment of features and bug fixes to customers while reducing risk and overhead.
In CD, a change can be deployed when (and only when) it has passed automated testing and can be independently rolled back. If this concept is new to you, I'd recommend you read Continuous Delivery by Jez Humble and David Farley.
Automated testing
Required for continuous delivery, automated functional testing, automated regression testing and continuous integration, is necessary to create confidence that the developed change is defect free. By utilising test automation software the execution of tests can be controlled and the change can be automatically validated against predicted outputs. Test automation software can undertake 1,000s of regression tests in seconds and help to ensure that each individual change has not introduced defects or unexpected behaviours elsewhere in the product. Note however, that the cost of developing an automated test base for existing products without any previous automation can be significant and the cost/benefit ratio will need to be determined on a product by product basis.
The adoption of Test-Driven Development (TDD) techniques, the practice of writing your test cases before undertaking work, will also ensure that there is a link between good design and testing.
DevOps
Finally, dedicated outcome teams need to practice DevOps. DevOps "stresses communication, collaboration, integration, automation and measurement between software developers and operations professionals" to ensure traceability of a change from development to production and maintenance. This also means that any defects that slip through can be rolled back and resolved by the original developer seamlessly.
Final Thoughts
There are always exceptions to #noprojects. Highly predictable & repeatable work, new products, corporate mergers, etc. A project structure can provide a "clean break" for these new ideas to flourish, but for most organisations should be an exception not the default delivery mechanism. Projects are exactly that, an exception to business-as-usual and you should be in the business of change.
This is just a start, and will be explored over a series of articles over the next few months. But don’t fall into the trap of treating continuous change as 1 long project (no matter how agile).
Let me finish with the key principle behind this. Everything is a change, treat it accordingly. #noprojects
* As always, common sense applies. This is a dramatic and general statement and as such is generally true but not specifically true.
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.