Teach scheduling to any class of IT project managers, and the number one request is invariably “How do I make my schedules more predictable? How do I accurately predict important events such as application releases?” There’re really two answers to that question – neither of which are mutually exclusive:
- Only use dedicated resources on your projects. It’s the interplay between break fix and new builds that dooms project schedules in your “normal” IT department.
- Incorporate buffer into your schedules. Buffer reduces volatility in date predictions.
Needless to say, option #1 is a nonstarter in most organizations. The challenge with the latter is that it requires an organizational shift. It requires different communication techniques and different reporting. Instead of reporting on a forecast release date, I report on a target release date and the probability that I might actually hit it. That’s the cultural shift required to move towards more predictable scheduling.
Nowhere in IT is this cultural shift more evident than in the relationship between the project manager and the release manager….
What Do You Mean I Can’t Release Tomorrow?
Release managers are incredibly annoying with their change processes, their release reviews and their insufferable insistence on having actual documentation. They represent the worst of organizational process and present an obstacle to getting my application in production and letting me finally wipe my hands of my current project and move on to something new and interesting.
Not only that, but I think they only care about increasing the costs of any project I’m on – whether it be by requiring an inordinate amount of hoops to jump through to actually get an approved release window, or forcing my team to spin cycles performing extra validation and testing on our application. I mean, we know it will work. It worked in Dev, right?
These are natural sentiments for a project manager. Over the months and years of a project, the project manager learns to look out for his project. He becomes focused on his project. And as he knows, his projects are always far more important, far more critical to the organization at large than any other project within the portfolio.
Look to Big Oil for the Answers
A couple of years ago, I had the opportunity to dip my toes into the water of oilfield maintenance scheduling. It was actually my first engagement upon moving to the Houston oil patch. For those of you not familiar with maintenance scheduling, it looks something like this:
- Whenever a new facility or piece of equipment is commissioned, a series of maintenance routines are loaded into a Computerized Maintenance Management System (CMMS). These routines might call for quarterly inspections, monthly cleaning procedures, filter changes, belt changes, lubrication, etc. Think of your local Starbucks, and all of the equipment they must maintain – and then multiply that by all of the Starbucks in your market, and you’ll get the picture.
- The CMMS spits out tickets whenever they’re ready to be worked. This feeds into the scheduled maintenance backlog. Each time a ticket is created, a timestamp is recorded, and the age of the tickets begins to be tracked. I don’t know what a “typical” backlog is, and assume that varies by industry, but figure a backlog of anywhere from 6 months to several years is reasonable – depending on the priority of the ticket and the industry.
- Those tickets go to the various work crews that do the work. As they have a set of specialized skills and equipment, the same work crew would be responsible for supporting multiple facilities throughout the oilfield. Going back to our Starbucks example, these are the tier 2 support team that are responsible for the hard core equipment maintenance (assuming they exist. I know next to nothing about coffee house logistics). It’s up the work crew to optimize their schedule so that they can meet their performance metrics.
- Enter the facility operator role. The facility operator is in charge of the safe and productive operation of his facility. His job is to ensure the facility meets its production goals and reduces or eliminates any reportable health, safety or environmental incidents. The facility operator has the authority to turn away a work crew that arrives on any given day if the work they are to perform is considered too dangerous….i.e. a simultaneous operations (SimOps) issue, where one crew is performing work in close physical proximity to another crew. For example, one crew might be welding while another crew is venting flammable gasses right next door. One crew might be slinging steel overhead while another crew is swapping out equipment belts below. For obvious reasons, SimOps issues are to be closely monitored and avoided at all costs. Turnaway metrics are also monitored, as they entail cost: the work group geared up, schlepped out to the facility, and then got turned away – which could potentially kill an entire morning or a full day of productivity.
- Hence a lot of organizations have moved to a system where the CMMS tickets are pushed into a scheduling optimization system. Trained schedulers then review all of the tickets and assign target dates based on priority, geographic proximity, risk and other factors. They “bundle” maintenance by the same crew in the same area to ensure increased productivity. This system optimizes maintenance ticket throughput, reduces turnaways (inefficiencies), and mitigates risk both of individual harm and the systemic risk of a high maintenance backlog.
In essence, what we have here is a number of systems being optimized for their own goals:
- The CMMS is identifying the tickets that must be performed and tracking the aging metrics.
- The work teams are focusing on their own daily marching orders.
- The facility operators are focusing on the safe operations of their facility.
The schedulers’ role is to balance the needs and wants of those groups with the overall priorities of the organization – which in an oilfield is typically mitigating risk of both reportable incidents and production stoppage.
And IT Folks Should Care Because….
Release management is essentially the same series of systems, writ small. The project manager is focused on the local optima, getting that release out the door as soon as possible. The release manager is looking at all of the releases coming down the pipeline and optimizing across the entire infrastructure. Everyone is just performing their natural role in the systems, and the release managers represent the organizational check of a project manager’s native optimism.
Generally, the way we see this playing out is that the project manager, through the development of the schedule model, creates a prediction of when the application will be ready for release. That date is then negotiated with the stakeholders and the release manager to pin down an approved release window.
That release window is then inserted back into the schedule as a target or constraint on the actual release event. Mechanically, within Microsoft Project, that looks something like this.
See how I’ve inserted the release window as a Release Target – which is basically a repurposed Deadline field? I then add a Start No Earlier Than (SNET) constraint on the successor tasks. In effect, this adds buffer to my schedule, as I can now track the Total Slack on the Release Activity. The lower the Total Slack, the greater the chance that I’ll miss my release window.
I’d point out that adding buffer is nothing specific to IT project management. I’ve recommended a similar approach to predicting pipeline completion dates in a drilling scenario. That helps us avoid the dreaded WOPL, where the well is completed, but Waiting on Pipeline.
…Bringing it Full Circle…
So, what we have in the interplay between project and release management is the same interplay we see in oilfield maintenance. We’ve got two different systems that interact but are focused on different optima. The project system is focused on getting the release out as soon as possible. The release system is focused on ensuring the enterprise infrastructure doesn’t break. The goal then is to incorporate into our project scheduling the feedback to and from the release management process.