Thanks to Derek Huether for bringing up the excellent topic of bringing projects to teams instead of spinning up a new team for every possible need within an organization. Having looked at numerous organizations trying to balance the demands of running too many projects, this is very good advice. However, I think there’s more to this than simply bringing projects to teams. It does not yet answer the root cause of why we try to run too many projects, nor does it answer the key question when that executive responds, “well, Agile’s great, but I would need 5 times my current staff to run all my projects as Agile projects”
Why Do We Run Too Many Projects?
My colleague Mike Dwyer refers to Scrum as a Silver Mirror. By this he means that, while it won’t solve all your problems like a mythical silver bullet, it will present you with a level of reflection such that you can identify and confront your problems. To that point, my perspective has been that organizations struggling to launch Agile projects because they keep trying to run too many projects are suffering from a larger issue.
- Lack of Agility
You may find this counter-intuitive, but I would posit that many traditional organizations use broad project portfolios as a means of achieving agility. With the heavy ramp up costs of any given project, having multiple options to respond to change. We can ramp up or down our energy on any given project based on changing circumstances or priority. While it’s not terribly flexible, it does offer some level of adaptability. However, it comes at the price of running all these projects at the same time, which is a very steep tax when you start adding up the cost of multiple status reports, daily or weekly meetings, code branches, design documents and any other overhead required for running your projects.
- Lack of Impediment Removal
I remember before I formally began my foray into Agile project management being frustrated with a manager about a policy of putting everyone on 2+ projects at any given point in time. After some lengthy discussion, he finally explained to me that by putting my on multiple projects, even though it would extend the delivery date of both, it would ensure I was productive. For if one project became impeded, I could simply focus my energy on the other. This may be true, but it completely hides the fact that we have issues with a project. It also defer risk by redirecting effort to the less impeded area, creating a false sense of a rate of progress.
- Lack of Priority
In some organizations, especially with many influential stakeholders, prioritization can be difficult. I have seen organizations where prioritization is implicitly thrust upon the development teams. The business basically asks for everything at the beginning of the year and then the technology partners respond when each item will deliver. Of course in these cases, the vice of no prioritization can be mixed with a desire to “show progress” on all projects with awful results. This is where we see more projects run than people so that some portfolio dashboard can show progress on all these different capabilities, but unfortunately it is really just an illusion.
I enumerate this list not to justify behavior, but to empathize with the conundrums facing many project managers. In fact, I believe that – in a strange way – the propensity to solve every problem with a project is a testament to the success of projects within large organizations. A generation of business people have seen careful project management get things done in chaotic and uncontrolled environments. Good project manager have leaped into the void of poor organizational impediment removal and prioritization and responded to these challenges by starting more projects. The only problem is that slowly the added cost of running these projects undermines our ability to do anything. This is a problem more projects can’t solve. As Albert Einstein famously observed, “Problems cannot be solved by the same level of thinking that created them.”
This level of thinking has reached it’s limit. We’ve gotten to the point where organizations deify projects to the detriment of teams and people. How many of you have seen organizations that will never stop a project, but they have not problem asking someone to work 25% or less on multiple projects across a portfolio? Or companies that talk about the value of teams, but keep sloshing people – probably referred to as “resources” – between projects on a regular basis? Indeed when we see this situations, where people feel totally at the mercy of the projects to which they are assigned, is it any doubt why people don’t self organize into hyper-productive teams?
Kill Your Projects, Get More Work Done
Several of my coworkers have toyed with the concept of “killing projects”. This would be the natural progression of Derek’s earlier point about aligning projects to teams. Its a great idea, but in many organizations, we may never be able to realistically say no to several projects in order to focus on a few. There may be numerous stakeholders with very real concerns that demand action immediately. Or perhaps we are simply within the bowels of a large organization and we are presently unable to influence our stakeholders to the point where they would pick one project over another. In the old days, we would slice apart people to make whole projects. Today, I’m proposing that we take the knife and apply it to projects instead. Rather than try to run multiple projects.
By leveraging a single product owner or product team to triage and break apart the work, we can feed what would have been multiple projects to a single team. This frees the team to figure out the best way to balance the work. If they are operating according the practices of producing production ready code every iteration, then they will also be able to deliver value to all stakeholders, something that would go a long way in those low trust environments where teams needs to show progress across all fronts. The other benefit is that by putting all requirements through a single funnel, they bring the different stakeholders together to discuss what’s ultimately most important.
They don’t need to work together. I’ve seen teams allocate the capacity of there throughput based on funding levels. For example, imagine that three projects were approved: Project A funded for $250,000, Project B for $350,000, and Project C for $400,000. This would lead to a single team funded at $1,000,000. We could easily allocate the team’s velocity by funding levels, thus each team would get 25%, 35% and 45% of the points delivered for each sprint or throughput on a kanban system. Either way, stakeholders would be able to get what they want based on their funding, but hopefully putting them together would lead to the model described by David Anderson (2010) where people would move through phases of first selecting work based on their allocation, then moving to some sort of democratic model and eventually moving to a model where they dialog about what’s most important for the organization next. This model could even be scaled to multiple teams, where they would pool requirements across different projects and figure out what they can build for the next release. These joint planning sessions are usually quite energetic with multiple product owners, teams, and stakeholders operating in breakouts within a large room to trade stories, make prioritization decisions and plan the work.
Ultimately, we are proposing a model to help you confront the issues of your organization. In order to be successful with any type of project portfolio strategy, we will need to be courageous enough to look into that silver mirror and address our shortcomings. It is the fact that the multiple project strategy hides these issues that is most dangerous. Not only does it offer little in the means of helping us address impediments or answer prioritization questions, it conspires with us to brush all of those things under the carpet and simply look at the problem as one of planning and organization. Those are safer topics to be sure, but we do ourselves and our organization a disservice by not confronting the real challenges.