The End of Projects: Moving Toward Evidence-Based Software Investment
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The launch was successful! Six months selling the board, the CEO, and the VP of Product Management on the idea. Four more months working on gathering funding and support throughout the organization. A two-week stint of project inception-building a master story list, prioritizing the list, and subsequently defining a minimum viable product. Another two weeks in iteration zero, getting staffed, set up, and ready to deliver. Now you'll spend the next who-knows-how-many iterations forming, storming, and norming before finally getting to performing. And over the last five months of iterations, enough value will be delivered to consider the project a success.
Wow. That was a lot of work! Time to split up the team and do all that setup again!
Really? After all that pain, suffering, and ceremony, is it really wise to take your working delivery climate and throw it to the wind? Once we've hit the end of a project, does it make sense to split up the team and start anew just because some arbitrary end date has been reached? Of course not, but this is something that frequently happens, mostly because we choose a strange thing called "project" to be the primary corporate unit-of-work.
Heretical Questions
An organization embarks on a project in order to produce a specific deliverable. There's the project to build a highway; the project to design a new marketing campaign; and, of course, our familiar software projects. We seem to use projects naturally as the unit of work for getting big things done. There's something very comfortable with the cycle of planning some big thing, funding it, and creating it.
Do we use projects for all things in corporate or personal life? Of course not. When my shoe last became untied, I didn't write a project charter or hire a project manager, and I certainly didn't ensure SOX compliance! To be kind, that would be a little too much overhead and ceremony. The same goes for things in corporate life. We don't charter projects for routine things that we just do on a day-to-day basis.
Imagine daily delivery of useful software that increases profit, improves productivity, or advances some other issue that's important to us. We may have a strategy for how we sequence features. And, who knows?-there may even be a backlog of work to do! But first let's ask two heretical questions:
- Do we need projects if we can make close-to-real-time decisions around what we work on next?
- Do we need projects if we have a continuous-delivery engine that allows for constantly testing the return on investment of what we do?
In such a world, we have to ask: Why do we need projects to drive successful software delivery? Why can't we just continuously fund teams that happen to have achieved continuous achievement of measurable business value? Do we need software projects—as we have known them in the past—at all?
That Project-Management Office Isn't Free!
There may be companies whose projects just happen to consist of a bunch of related activities that a group of people may do, bounded by start and end dates, and with little ceremony, no compliance officers, and almost no overhead. But this description probably doesn't fit your company-nor does it describe any clients with whom I've worked in the last 18 years.
Let's face it: Once you have a project, you suddenly start to spawn lots of things that exist only to govern said project. You start with a Project Manager. Eventually, you get bigger and start adding sub-projects. Before long, you have a Program Manager as well. You start to get lots of attention from other departments, adding a Risk Officer or Compliance Officer, something called a Project Office, and who knows what else. Not to put too fine a point on it, many companies develop all sorts of well-intended governance like this, most of which is designed to manage the risk that the people who actually write the code would spend nine months writing a Facebook clone, rather than that time-and-expense app they were chartered to write.
Most of this overhead, save perhaps a "capital M"-Manager type with a singular goal of keeping the team unblocked from progressing, is wasteful, in a model where you have less risk. One noble goal of continuous delivery ought to be to reduce risk to such a safe level that you can lose most of your governance people and still be confident that you won't inadvertently deliver Microsoft Bob.
Imagine a World (Mostly) Without Projects
In the post-project world, we don't perform "teamicide" at project end-breaking up well-oiled, running teams that are continuously delivering—just because of an arbitrary end date. While we may rotate individuals so that they won't get bored by working on the same product for years on end, we make these changes strategically, so we can keep the good dynamic going on the performing team.
The post-project world allows us to have a more flexible funding model. After passing the MVP stage (that is, getting in place a minimum viable product), you can start funding projects in the smallest increment you can stand. While the specific accounting mechanism (capital expenditures versus operating expenditures) is beyond the scope of this article, the ability to leverage investment up or down dynamically according to potential ongoing value delivered is a powerful tool.
Most importantly, though, the post-project world drastically decreases software delivery risk. It lessens the severity of failure, allowing people to try bolder—and possibly more groundbreaking—ideas, without having to worry about bankrupting the company in the process.
Inceptions and Initial Product Investments
Sadly, the post-project world I'm describing isn't a purist's paradise, where you no longer have project managers. In the post-project-centric world, you still need something that looks like a project during the phase that gets you from idea inception to a minimum viable product. Getting to that point may even take three months, require SOX compliance to get to the production gates the first time, and adapting other parts of the compliance machinery we've invented over the years.
That said, there is a key difference: The project of the future I describe is rarely more than a three-month endeavor. In fact, it may be shorter, in an environment like Google, which allows people to produce independent skunkworks products in their "20% time" (the amount of time that employees are given to work on things they believe will bring value to the enterprise). Smaller projects, lower risk, less need for the kind of strict controls and planning overhead that gave rise to the Agile movement in the first place.
Software Solutions Aren't Bridges
The minimum viable bridge across a canyon has to be pretty close to done. For bridge-building, the MVP is very close to the point at which incremental effort only marginally improves the product. Once you have your basic bridge, you may put up some signage to make it a bit more marginally useful, but the bulk of the product will likely get the job done.
Software, on the other hand, really is different. It's, well, soft. If we employ good engineering practices, we can make that software able to change quite radically. Further, in many cases, ongoing opportunities for improvement are available beyond the initial vision. Seldom do you encounter the piece of software that's so perfectly evolved that there are no more opportunities to improve it significantly. This is particularly true with respect to internal line-of-business systems that historically get scant attention from user experience experts.
This Isn't Realistic! My Company Runs on Projects!
I have no illusions that the world will stop being "project-centric" anytime soon. In most large companies, the idea of losing comfortable controls around projects is truly heretical. Billions of dollars have been spent creating project management offices, investing in project management professional (PMP) training, and so forth, in companies of all shapes and sizes. This isn't the kind of thing that gets reversed overnight!
However, early-stage startups generally don't hire deputy vice presidents of this-and-that in order to staff a formal project management office. In the startup world, you create a very basic product, prove it works (what Paul Graham calls "ramen profitable"), and only then start to get ongoing funding.
If we really think about it, we could describe how projects are funded today as a "faith-based initiative." You do a lot of upfront analysis, perhaps run some focus groups, but when the rubber meets the road, you spend a lot of money and intellectual capital chasing something that may or may not materialize. This alternative, which I humbly call evidence-based software investment, removes the need to fund software development based on faith or hope. Building on continuous delivery, Agile, and common sense, it has the potential to allow investment to more quickly find the work that adds the most value to the organization. Perhaps it's time to give evidence-based software investment a try!