Not everything in IT needs to be a project – by de-projectizing maintenance work major improvements in delivery are possible.
In particular, the ‘Scrum’ variant of Agile offer the interesting option to de-projectize a lot of IT maintenance work in much the same way a large amount of physical maintenance work is undertaken by a team of ‘maintainers’ working through a backlog of prioritized issues. Where an IT shop uses stable teams, ‘scrum’ to plan work on a monthly basis and ‘sprints’ to deliver weekly improvements; the situation is totally focused on routine operations. Stable teams working on dozens of minor objectives selected on the basis of an organization wide prioritization is the antithesis of a project. Projects are delivered by temporary teams assembled to work on the unique project deliverable (as described in the Project Charter) and then reassigned to other work as the project closes down.
The potential for substantial improvements in customer satisfaction that can be achieved by removing the ‘project overhead’ and using the flexibility of Scrum to focus on immediate priorities should offer a useful maintenance methodology for many IT applications provided the appropriate disciplines of documentation, etc are maintained.
These underlying principles would be very familiar to the maintenance managers of most large facilities. A stable crew of maintenance workers, familiar with the plant look after the prioritized day-to-day maintenance issues and install minor improvements. This routine working environment only gives way to ‘project management’ when a major outage or change is required. Probably the major difference is traditional maintenance management tends to sit inside a functional organizational structure whereas ‘Agile IT maintenance’ seems to operate best in a matrix/collaborative environment.
In one sense this is a ‘back-to-the-future’ development, recognizing IT as an enabler to achieve business success in the same way a well maintained plant is essential to a manufacturing businesses success. And whilst both the IT infrastructure and the ‘plant infrastructure’ need routine maintenance and upgrading; there is a key difference. The enhancement of an IT infrastructure involves far more creativity and offers far more opportunity than plant maintenance. Combine this with the idea of actively involving the users in the development process encourages synergistic improvements.
Whilst this is definitely not ‘project management’ as we know it; there is definitely an emerging practice that has enormous potential to improve the day-to-day operations of many organizations with a large IT infrastructure. I believe the ‘Agile debate’ needs to expand to recognize there are places where traditional project management works best, places where a project can use variants of Agile to optimize the project delivery process, and importantly places where project management is an unnecessary overhead. What do you think?
Comment
To an extent, it depends on your circumstances Michael. Industrial maintenance has made effective use of both processes for decades. Day-to-day and emergency maintenance is an operational function with a stable team and entrenched expertise about ‘their plant’. Major changes and refurbishments are typically planned as part of a ‘maintenance shut down’ which is typically managed as a very intense project with significant pre-planning, preparation work and a large influx of external recourses to minimise down time. Lost production costs in the order of $400,000 per 8 hour shift focuses the attention wonderfully!! I think IT management could learn a lot from this model.
Comment by Michael Murphy on January 10, 2012 at 10:17pm I've never understood how maintenance got stuck under Project Management. The basic definition of a project is that it has defined beginning and a defined end. Maintenance has no end - it is ongoing, repetitive work. Always seemed like senior management, suddenly exposed to this new fangled thing called Project Management, decide if it's good for round holes and hammers, it'll be good for square holes and screwdrivers.
To those who would say that a bundle of maintenance changes constitute a 'project', think about what a project means - you gather a team together to build something for the customer. The customer has a vision of what the thing will do. Maintenance fixes - that's just a collection of widgets - it'd be like declaring that the work to build and package a truck load of widgets is a project because the widgets are all bundled in the same truck.
Regarding Agile and Maintenance, I wonder if Maintenance and Scrum might collide quite a bit if the maintenance is such that there are lots of critical "fix this now" situations, unless the spring is very very short. In IT maintenance, when the 'fix this now' comes in, it is not sufficient to say "wait till next sprint". Which means there will be lots of "distracted' time logged for each Scrum team.
Whether using Agile to gather maintenance changes into a bundle, or using some other mechanism to package the changes, IT maintenance never has and never should be managed as a project.
Thanks for the comments.
I started working life as a builder and have specialised in project controls for most of the last 40 years so my thoughts on Agile are from an ‘outsiders’ perspective. What I have tried to do is compile a simple jargon free assessment of the overall concept at http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf - you are welcome to use this.
The question raised by Taras is more significant – managing the change generated by any project is critically important (as one change expert pointed out “projects are the messy bit between a great idea and using the idea to generate benefits”). This was the focus of a post some time back, see: http://mosaicprojects.wordpress.com/2009/07/26/the-scope-of-change/
Comment by Gregory Correll on January 10, 2012 at 11:03am I agree that maintenance need not be a project. I'm not familiar enough with Scrum and it's processes to know how it fits in with Change Management. Most organizations that I've worked with require allmaintenance to go through the Change Management process. (I've seen people fired for performing maintenance outside of an approved change window.)
This usually entails a review. How does this fit into the scenario described above?
Comment by Sarita on January 4, 2012 at 7:49am That's true. Not everything is a project. Because its a collection of tasks (directly connected or allied) that needs completion.
Nice article.
© 2012 Created by Miles.
You need to be a member of Project Managers to add comments!
Join Project Managers