10

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.

  • What methodologies do the software teams follow? Some mix of agile, waterfall? – Jesse Sep 25 '11 at 2:29
  • It's a mix really, but no specific methodology. Communication is pretty good within the organisation, therefore people know the things they should be working on and just do what it takes to get the work done (including extra hours if required). However it's starting to reach a point where some 'orchestration' is required as more work is won. – cw84 Sep 25 '11 at 16:50
  • Once you have allocated someone to a piece of work for a given period (or until that work is finished), do they stay there, or are they likely to be dragged onto other work as priorities change? – Iain9688 Sep 25 '11 at 19:28
  • Yes, sometimes unforeseen 'urgent' issues arise that interrupt the planned work. – cw84 Sep 25 '11 at 20:56
2

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.

6

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.