How can I make company-wide scheduling and resource allocation decisions?

Question

I've recently been taken on in a Programme Management role for a software company. There are several definitions of Programme / Program Manager out there - my role encompasses, amongst other things:

• Managing scheduling across the company's projects
• Managing resource availability
• Making accurate projections as to when future projects will be likely to go-live

My former experience is working in a Project Management role with a dedicated team solely working on one project at a time, but I'm now in a position of needing to juggle the priorities across multiple projects, with resources shared between those projects.

One of the biggest challenges I face is that it's simply not practical for the team to accurately estimate projects that aren't due to commence until two or three months time. But there is still a need to timetable the work.

Are there any methods / approaches that can be applied here? I'd welcome any thoughts.

Answer 1

If your team's aren't delivering work in a similar fashion then putting together a time table of estimates down the road is going to prove to be challenging.

However, with that caveat out of the way here are some things to try for generating high level estimates. I say high level as I have found it more efficient to generate a high level estimate for roadmap projects that are further down the road. This doesn't apply to all software projects or companies however, it seems like it may fit for you.

That said, please keep these notes in mind:

• Your teams should be the one providing these estimates to you. They are the ones eventually going to be doing the work and as such should have input into the estimation of the tasks and the length of time they will take.
• As the program manager responsible for communicating these estimates, you need to keep in mind that they are an "estimate", not a commitment of roadmap work to be delivered on dates x, y and z.

Break down the project into its larger pieces of deliverable business value with the team (functional requirements, epics, modules...etc..) Have the team estimate each of these larger pieces of work:

• Prior to putting an estimate, the team should be clear on what each piece of work contains. They don't need to discuss the technical implementation of what each module does or will do but rather the desired outcome of the module.
• The estimate can be in weeks, months, developer days, story points. As your not following a specific methodology you will need to try and find out what works for you and the teams.
• Sum the estimates on the large deliverables of the project and fit that into your roadmap.

Keep track of historical data:

• Do you have historical data for work previously completed? This data can be very valuable when determining estimates on future projects.

Make the roadmap an expected range:

• As you haven't broken these projects down into a find grained estimate, you can estimate with a range. Project alpha is starting in 4 months and we estimate it will take between 4-7 weeks to complete. As you get closer to working on the project and the requirements are estimated in greater detail, the goal would be to say, given our current scope and resources project alpha will be be completed within 3-5 weeks.

In closing, again I will mention that if your teams's aren't following any specific methodology and are all over the map, that is the first thing I would change in discussions with your development managers and teams.

Answer 2

To borrow from Stephen Covey, I think you're focusing too much on the urgent, at the expense of the important.

You're trying to manage/juggle multiple projects (and the resources that are both needed, and will be needed). But you say it's not 'practical' for your team to accurately estimate. I note you didn't say it's not 'possible'.

Look at it this way, your team is going to have to give you an estimate, now or later. 'Now' gives you time to project the projects needs and start allocating resources (you know, your job :) ). 'Later' you'll still have to do it, but in fire-fighter mode.

Your team may not like having to do it now (since it seems impractical), but later when everything is already planned and allocated for they'll appreciate it.