I.T. infrastructure should be fluid – being constant reviewed, growing and adapting as the business grows and changes, so if you need to run a project, it stands to reason, 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 and I.T. Intelligent, 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.
You may need to bring in additional staff early on, but with good resource management and capacity planning, this can be managed across different demands. I.T. often does not have a dedicated Senior Manager which is a mistake unless the I.T. staff are experienced – if not the organisation has already planned to fail – Organisations need to appreciate that I.T. needs adjustable time and continuous, applied resource, with this predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies.
Projects address a static need
The intent of any project is to address an identified need, whether internally or for a client. However, a client 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, client 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 and the sustainable values. Fundamentally, teams work on activities that create a change within the context of an outcome. this is managed through the Activity Canvas and Outcome Profile.
Projects are expensive
There is implicit, and explicit costs 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.
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.
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, therefore, 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.
One of the primary reasons organisations use projects is to predict and control budgets and financial spend. Putting aside the previously referred to 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.
Leadership of Value Delivery Teams
Continuos I.T. improvement is as much a cultural change as it is a process change. As such the senior management team 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 but need to be explicitly stated by the senior management team. 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.
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.
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/benefits ratio will need to be determined on a product by product basis.
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.
Continuous Change occurs naturally in everyday business – we manage impacts and unexpected circumstances daily – in fact, it is this ability which is a requirement of senior managers, so why do we deal with I.T. as a static project so often? Technologies are changing rapidly and the project management approach will not keep up with the speed of these changes – organisations need to adapt their approach to “stay ahead of the pack”
