We don’t set up projects to manage every month’s payroll run and we probably don’t need projects to manage monthly software releases either.
Over the past several years, our consultants have worked with some enterprise-class clients and government agencies to eliminate the notion of ‘projects’ from some value-chains or lines of business. In all of these cases, these organizations have desired to move away from a discrete project model of delivery to more of an unbounded, continuous flow of delivery model. And in all cases, our clients were looking for fast and flexible ways to support a portfolio of products that will be in need of continuous support and evolution for several years to come while both accelerating delivery and reducing overhead and friction.
Is the classical notion of ‘IT Project’ losing momentum as the de facto approach to managing IT delivery? With these clients, we have helped to develop continuous delivery capabilities that do not rely upon the notion of a project as a controlling mechanism. And isn’t that what a project is really? A control mechanism by which we control scope, cost, schedule, quality, etc? Might there be other means of control that are just as effective if not more so and with less overhead? While projects are in no danger of disappearing anytime soon, there is a strong and growing interest in reducing or even eliminating classical ‘projects’ as the primary management approach to IT delivery.
A project, per PMI, is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. The problem of course is that software products are never done. They are supported, modified, enhanced until they are retired and turned off, sometimes after a decade or more of almost continuous investment.
Projects vs. Products
Back in the era of long design/development/test/deployment cycles, often lasting a year or more, the idea of a temporary project resulting in a unique product or service may have made sense. But over time, we have finally started treating IT systems more like the long-lived products that they are. And organizations have responded by scheduling one project right after another pretty much forever. The result is that one spending-cycle is followed immediately by another and then another resulting in continuous spending over the long term. And so it should be for most products … but wait, can’t we do continuous spending just fine without all of that project overhead?
Certainly project management has led to improvements in cost control, scope control, quality, etc. But not all of the outcomes have been positive. We have all seen cases where project-centric thinking started to dominate over product-thinking sometimes leading to bad product decisions that do disservice to customers and users. “We can’t do that highly necessary feature, it doesn’t fit into our charter, it is out of scope, we didn’t fund for that, etc. We’ll have to roll that into the next project which, by the way, starts about 6 months from now after this one ends.” These kinds of decisions are clearly cases where the sanctity of the project began to dominate over the fitness of the product. The problem of course is that users to don’t see our internal projects; they only care about the product. The goal of creating great products for our customers in response to real and current business needs got lost somewhere along the way to ‘project management excellence’.
Also, DevOps has really accelerated the view of IT assets as long lived products that need constant support. DevOps completely breaks the old paradigm of one-project = one-release. Certainly projects don’t have to only deliver one release into production … they could deliver many … but that is not the common mentality. In the continuous delivery world, we strive to deliver frequently, many times per week perhaps into production. And with production monitoring, better customer analytics, A/B testing, feature-toggles, and a host of other techniques, we have developed highly adaptable rapid-response systems that do not necessarily warrant or require the well-defined up-front fixed-scope mindset that dominates most project thinking.
Financial Controls
But what about financial controls? How will we control and allocate costs? Well, dedicated agile teams are about as easy as it gets when it comes to cost. Dedicated teams have a fixed burn-rate. And since our products always need support, we can justify keeping the teams together over long periods of time. If a team has 10 people, and has a blended rate of $100/hour per person then the team spends $1000/hour = $8000/day = $80,000 for every 2-week sprint. Easy. The resource model is also easy … the team stays together and we do not need or want to split it up across different project efforts. We don’t send individuals off to work on projects, we bring the work to the standing teams. If we need to allocate the cost of that team across different efforts or products or cost-centers then we can easily do that without a project. If the team delivered 21 points this sprint, 7 points each across each of 3 different products, then we can allocate the full cost of the team’s sprint across 3 cost centers if we need to. We can measure day-to-day to see if we are spending too much in some business-areas vs others or if we are spending too much or too little on capital or expense. And we can make adjustments day to day in terms of which backlog items we choose to deliver next in order to get very fine grained almost daily control over how and where money is spent.
Scheduling
Scheduling is also pretty easy if we set it up to be so. We have worked with several very large clients to implement standing release schedules. For example, “We release to production at 3pm on the first Wednesday of every month.” Whatever is ready to go at that time gets released. Whatever isn’t ready gets rolled into the next release. The entire organization knows when releases are going to happen and everyone can be ready to support the release: production support, infrastructure, communications, help-desk, etc, etc. Scheduling really doesn’t get too much easier than that.
These releases are not temporary efforts or one-time events, they will go on for years potentially over the lifetime of the product. We probably don’t set up a project in our organization to manage every month’s payroll run and we probably don’t need projects to manage monthly releases either. And even the idea of monthly releases is starting to seem like an eternity in some fast moving organizations.
Risk Management
So scheduling is relatively straightforward when you schedule for frequent and regular delivery. And financial control is relatively easy when we bring the work to standing teams. But what about risk management? Where does that fit in? A bit of it actually goes away! A fair bit of risk management goes into protecting the schedule and cost, much of which goes away as a concern once we eliminate release schedules and burn-rate as variables. We fix these and so they are known. But there are still plenty of risks and agile does a pretty good job of risk management as a matter of course, but we can manage risks without setting up a lot of project overhead.
Value Delivery
That leaves value delivery as the primary variable and driver of success. And this is where we should be focusing our thoughts and efforts. What are the features that are going to gain us the most efficiencies, satisfy the most customers, reduce the most costs, drive the most revenues? Most of our organizations are ill equipped to make these sorts of tradeoffs because we have not been trained to think this way. We used to just ask for everything and then try to deliver all of it over a multi-year program efforts. Now, we need almost daily tradeoffs on which which features to today and which to put off until later. And that requires intimate knowledge of our customers and users which we still lack in most cases. This is where real effort should be spent. We’ve spent years developing our project management skills but we are woefully behind in our product management skills.
The Bottom Line
Now let’s be clear. Projects have their value and place and they aren’t going away anytime soon. Large-scale revolutionary efforts and huge programs that are so large that they almost need their own complete management systems are still prime candidates for project management.
But we are quickly moving away from big-bang revolution towards a model of fast and continuous evolution of products and the project paradigm may no longer be the best or most appropriate management model for many of our IT efforts. And if all of this sounds like pie-in-the-sky dreaming or something that could only work with startups … remember that we have already worked with some major commercial and government clients to implement these ideas.
Roland Cuellar (‘kway-are’)
