Attack of the knee people: or How I learned to stop worrying and love fractional resource allocations…
Somewhat recently I was asked to lead a new software development effort at my organization. As we were building a novel product in a new domain, the project pulled a lot of focus. The wheels of management turned and much time was spent putting together a development plan to include who should work on the project and exactly how much of their time they would be allowed to spend on that work. When I finally received a copy of that plan, the effort allocations looked a little bit (exactly) like this:
- Person A — 50 %
- Person B — 20 %
- Person C — 10 %
- Person D — 10 %
- Person E — 5 %
We were given 10 weeks, so I thought a first step towards helping the project be successful might be to identify some dependencies and risks that would put that timeline in jeopardy. In my mind, one non-trivial risk was the lack of people actually committed to the project. Pictures being worth 1,000 words, I thought I would make that point with this:
Sitting down with the team we all saw the same problem: if you are less than a knee person how can you really contribute to the project? If no one was fully committed, then we would need some waist and chest level efforts to generate and keep momentum. The commitment from anyone with only a foot in the project would be fragile and susceptible to disruption.
Feeling bothered by this, I decided to track actual effort over the 10 weeks of the project, surveying the team each week to ask them roughly how much time or effort they spent on it. I did this for two reasons. The first, obviously, was risk management: were we able to put in the work? If we couldn’t, then it was best to know early and raise a red flag. The second was for a reality check. If this project were successful, we would likely be investing more in similar projects. It would be useful to have a baseline for the amount of actual effort it took to complete the project to inform future development plans. The results are below:
Remember that total effort for the project was supposed to be .95 FTE. We only had one week out of 10 where we were under that amount. (Unsurprisingly, also the week where we accomplished very little.) Fortunately we were able to keep the team very much engaged in our project. In the end our team actually looked more like this*:
*Not counting skills outside the assigned team i.e. support from operations (databases, servers, build pipelines) and design (icons, graphics, ux).
True to our initial expectations, all of the project contributors had to get their legs under them. The one person who ended with only a foot in was basically just keeping up with the project and staying informed, not actively contributing. Also not obvious from the end result, but one of our knee people ended up being out of the office for 4 weeks of the project. Were we to factor that out, her effort relative to time in office would have been higher.
The good news is that we made our deadline and delivered an application that met the the project sponsor’s expectations. While doing that we learned a lot that would reduce some uncertainty for future projects. While I’m happy to take a win and celebrate success, I can’t help but wonder about the cost of that success.
In the same way that every exit can be viewed as an entry to somewhere else, all of our knee people were chest people to someone else. Given our experience that there is a minimum commitment to a project required for one to truly contribute, what happened to the other projects those people were supposed to be working on? Did they fail? Were they delayed? What was the cost of that delay and was it a reasonable trade for the value that our product delivered?
The way I see it, we were simply kicking the can down the road. We chop up people’s effort in order to start projects, but end up creating an environment where each team needs to compete for their attention. One problem I have with this is that under these conditions someone is going to lose. The type of work we do requires some focus and, occasionally, specialized knowledge and skills. When teams compete with one another, there will be one that misses out on one of these. Maybe it won’t have enough people to complete the work it is expected to do. Maybe it won’t have enough of the right person’s attention at the right time to solve a critical problem. Those risks are inherent in the work to begin with, we don’t need to introduce a system that exacerbates them.
In setting up projects to lose this way, we forgo our ability to make informed decisions. Certainly we are deciding to invest in projects that we think will benefit our organization, customers, or users. But we are abdicating our responsibility to decide which of those projects we won’t do so that the others are more likely to be successful. Instead we are leaving that important decision to chance.
Like I said, we happened to be successful in our project, but I think if we, as an organization, are interested in long term success, then there has to be a better way to manage our projects to set all of our employees up for success.