Information Technology

Retrospective

I’m writing this from week nine of thirteen in our first quarter of project budgeting. We’ve accomplished a great deal, though we had to defer some work as well. As we’re preparing to embark on another round of prioritization discussions, I’m hoping to find some ways that we can improve this Project Prioritization Process (we’re calling the framework, P3). Here is some feedback that I’ve heard; I’ve tarted these up into imaginary voices, they aren’t meant to be literal quotes.

The developers showed up, worked for a week and then were gone.

We generally had very short amounts of time (one or two weeks) to work on things, so we didn’t necessarily get everything done on any one project as we had hoped. We sometimes met with stakeholders just prior to the work period which left little time to settle on requirements. We will be working towards a more formalized and polished method for working with stakeholders to select and confirm the work that is performed. We will also be reinforcing the ideals that we are trying to achieve: short iterations, added value to users and process, partner involvement.

You’re working on what?

Some stakeholders have been surprised about what we have been working on. We have been encouraging them to speak with their supervisors to help understand how the selected projects fit within the strategic goals of the organization. I believe that several divisions are having meetings prior to the next round so that they can decide as a group on their priorities.

So many projects to choose from!

Our Project Index is very large. How do you decide? We’ve tried to balance informative with readable which skews according to each person reading it. Some projects have links to fairly substantial plans and large lists of deliverables; some don’t even have a project page. Some are fairly light ideas that would be nice to do some day; some are of dire importance with hard deadlines. This list, even with our best guesses of impact and size, doesn’t necessarily impart that information. We might consider assigning a priority in the future, but I don’t think that we’re quite ready for that yet.

What are we working on this week?

The technical teams working on these projects were frequently dismayed at the amount of time that they had to work on things. By the time that we divided the number of approved projects across the time period and assigned them to the most appropriate team members, we had some very short sprints. The teams felt like they were not able to deliver the quality of solutions that they would have liked. They felt like they were under pressure to drop what they had just gotten up to speed on and work on something completely different.

The projects that we are asked to work on are complex and unique by nature, so there is a start up cost for each one, e.g. (re)acquaint ourselves with the code, arrange our virtual workspaces, understand the problem, conceive and vet solutions, etc. We can have a couple running concurrently, but effectively not more than that. We have a relatively small IT organization and like all IT shops, there are always systems that need to be maintained at the same time that you’re building new stuff.  We also want to develop our team, our skills and be engaged in the organization. So, for the next round of prioritization, we’ve learned that we need to limit the number of projects that we select to work on – two to five for each of the IT groups: ILMS, Development, Infrastructure.

All that being said, it was very nice to have a schedule of what we were going to be working on for the quarter.

I’m glad that I’m working on something that has value.

Of course, this process has had some hiccups, but it is working. We may have been surprised in a couple instances by what projects were chosen, but we truly value that this work is considered of value to the organization as a whole.

We are done working on that.

Mostly we ended up with what we needed by the end of a sprint, but frequently everyone walked away wanting a bit more. Not only was this process developed to determine what we should be working on, but to help determine how much effort we should spend. The large number of projects for this quarter probably skewed ‘how much?’ to ‘too little’ but we have the option of spending more effort next quarter if we need to, or if we want to. That’s a fundamental value of our team: delivering something of value is better than nothing.

What next?

The next prioritization meeting is January 10, 2014. and will encompass the time of February through April. Talk with Russell if you have more details for something new or already on the Project Index. Talk with your supervisor to ensure that they understand what it is and why it is important. Let Russell know if you have questions, suggestions or concerns about the new process – he’s happy to hear all.

Prototyping the process at a local eatery.

The OSU Libraries IT Division has a large to-do list. Very large. We have been working on formalizing the process for getting ideas on the list, and it has worked: we have 86 projects on our Project Index! We can’t work on all of them at once, so which ones do we work on first? How much effort should we put towards each one? How can we let the organization know that we are providing value and not just arguing the industrial merits of various gemstones?

The Meeting

The Assistant and Associate Directors agreed to help us prioritize the work and assign how much effort we should put towards it. For our meeting, I prepared a card for each project and distributed them to the appropriate Sponsors.  Each card had the project title, requestor, and a very brief description; the cards were also sized according to the very rough estimate of how large the project was expected to be: S,M,L,XL. As a group, we reviewed the projects: which ones were already active, which one had real deadlines, how they affected each other, how they fit with the Libraries goals.  The projects that the group selected to move forward with in the next calendar quarter were pushed into a pile.

That’s a start, but not all projects are equal, and we couldn’t hardly finish all 22 in the next thirteen weeks. The next step was to assign the relative effort that we were to put towards them – much like a monetary budget, there is a limited amount of effort that the IT division can expend on projects after we have answered all of our trouble tickets, meetings and day-to-day responsibilities. This we represented with poker chips and arranged them across the different projects.  The number of chips on each project signified how much effort we would put towards it.  This doesn’t necessarily mean that we would finish the project in that amount of effort, only that we would work on it. This seems like an odd way to go about things — after all, isn’t the goal of a project to finish it? We are trying to ensure that the amount of effort is proportional to the expected value to the organization.

The Results

Any meeting that is led by an engineer is going to end up with some math.  I won’t bore you, but we broke it out into the various resource pools to help us organize the next few months.  There were spreadsheets, it was pretty cool. Below are the projects selected for 2013-Q4, the resource lanes are something that we’ll keep for ourselves for now.

Next Steps

This is a large number of projects, but we’re going to have something of value to show for each one by the end of the quarter. Towards the end of the period, we’ll be setting up another prioritization exercise and we’ll be making regular updates in this space, so stay tuned.