Project Portfolio Management Lite
As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly random sources of work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.
In the first article, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we covered an example of using the work capacity metrics to support a frequent management question around the lack of project work progress for a team with additional production issue support responsibilities.
So, we have seen how the use of work capacity metrics data can be used to capture the impact of difficult to predict production issue support competing priorities. Let’s build on that with a more complicated example surround predicting how much project work your team can reasonably accomplish in the future.
A common question to an engineering manager that will be repeated over and over is: “We need to accomplish X and Y and Z … oh, and we need to complete the first Q milestones of project L … can we do all this by the end of the week/quarter/year?”
A completely valid question, but one that is incredibly challenging to answer: Clearly, the requestor is asking for some degree of confidence that all of this work can be accomplish or if it can’t, what can be reasonably expected and to what level of completion. Based on the answer, the requestor may consider re-prioritizing the work, or reducing “nice to have” features/capabilities or determining a completely different, potentially non-IT solution to a given problem. Given an answer of “I don’t know” or “I can’t tell you” or worse “yah, sure we can” without any shred of data to support that claim, the organization as a whole is already heading for a disaster of some magnitude.
Now, any IT project manager reading this is going: “hey, I do this for a living, let me take over …” I agree. What we are embarking on here is a slimmed down form of project portfolio management. From the engineering manager’s point of view, you have a fixed set of resources. You have work requests you have little to no influence over that you have to support. You also have work for which you have more influence but you probably have more work than you can reasonable staff with a simple: “Hey, Bob, go dedicate 100% of your time to Project X and come back when Project X is done for your next assignment”.
Feel free to type in “project portfolio management” into Google and be prepared for an onslaught of material to sift through. Try the same in Amazon or even the shelves of your local bookstore and you will find mountains of material on theories and approaches to this topic. But of all the material available, for someone that is looking for a quick and simple way to put together a mechanism to use some loose metric data to predict the future, I highly recommend Peter Kretzman’s post on his blog “The Practical CIO: Difficulties in project prioritization & selection, part 2” [].
In essence, you need a tool to help you put some metric data you have together with some work estimation data you extract via the requestor to produce some map of the likelihood, given your fixed resources and non-influence-able work requests that you can complete some portion of the work requests by some arbitrary date in the future. Or, stated another way, what you are trying to predict with data you can explain, the intersection between the number of resources you have, minus the percentage of time they spend on non-project work against the number of projects and associate work duration estimates. If you take on two many projects at once, your resources will be spread so thin they will predicatively miss deadlines on all of the projects. If you take on only a few projects but the work is lengthy and sequential in nature (waterfall application development comes to mind) for individual resources, then you will have idle resources but hours and hours of work ahead of the few engaged resources. As I mentioned above, Peter has put together a straight forward explanation with a simple MS Excel template you can start using immediately which I highly recommend you explore.
After exploring, you should be in better shape to handle the negotiations that ensure when project work requests exceed your team’s delivery capacity.
In the next article, I’ll apply the same approach to the “Projects requesting engineering support” request attribute.