How to manage consulting resources to deliver ahead of delivery dates?

Question

I am a PM for a large matrix enterprise organization that has internal development resources as well as contracted consulting groups. Depending on the project we may need to engage an application team that is one of the consultant groups. Each department in the organization is allocated project budgets so that they can pay hours to other departments resources. Usually this means collecting estimations from the project teams and then budgeting them hours for development.

I have noticed a trend during our projects that the consultants seem to always wait until the last possible moment to build, test, and deliver the product. Many times issues are found very late and thus require additional hours from our budget to resolve, along with forcing timelines to slip. For example in the current project the consultants had said it would take 3 weeks for development but every time I check in on them they then bring up issues (if I didn't ask I wouldn't know about it), and ultimately they are already 2 weeks behind.

I want to know if there are any strategies either in the day-to-day management of these teams or perhaps some other method to ensure early or on-time delivery.

I do not have the power to turn the team into an agile team, or anything as dramatic as that. Is there a way to add accountability to timelines since they report to a functional manager?

Answer 1

Lets assume that the consultants are working in good faith and their estimates are correct.

Now delays must be caused by the usual things:

• external task needs to be completed by someone else.
• extra requirements added during project
• missing external resources, api, servers, accounts etc

Enumerate and record the actual reasons for the delays. "what could we have done so that we would have known about and estimated for this issue which you are telling me about"

If it turns out that it is just the normal things, or the estimation is too low, then you just have to up future estimates or be stricter with your pre start procedures

If it turns out to be other things:

• we didn't start when we said we did
• I was allocated to another project at the same time because its worth more to the consultancy.
• we estimated low to win the contract
• we switched the engineers working on your project out for more junior ones

Then you need to look at what the contract says and change it

Answer 2

Sounds like working in a more Agile-structured way would be beneficial. If you require being able to see incremental versions of the software every so often (say, every two weeks), then you will not only be able to provide early feedback, this will also force issues into the open much earlier, as well.

Answer 3

I suggest we share the observation with the manager of the consultants, agree with him or her the expectation gap, brainstorm the probable motivation or ability root causes (for example, Start Late, if indeed that is agreed as a gap) and alternative solutions to bring about positive changes to close the gap and agreed on the next steps with ownership and timeline. Set up brief check-ins to follow up the progress made on the improvement plan. These processes worked for me in the past. Good luck.

Answer 4

I have noticed a trend during our projects that the consultants seem to always wait until the last possible moment...

I noticed you used the plural "the". The fact there's more than one group or team that is consistently delivering late indicates that it's more likely to be the management of these resources (see: the common denominator) that may need to change, rather than the resources themselves.

I'm in a similar situation with one of my developers who aren't delivering on time, consistently. Admittedly we're using agile, but the problem of late delivery and lack of communication remains, regardless of methodology. Some teams need closer management than others, need more guidance and more pressure to be honest when targets are being missed. I did the following:

• Shortened the delivery dates or review dates so instead of waiting 2 months to see if something wasn't done, I'd be waiting 2 weeks or 2 days. This highlights problems earlier, which can be dealt with earlier, and with less impact to the project
• Made it totally clear what was expected to be delivered, no ambiguity. This is important. It's not fair to blame a resource for late delivery if the deliverable wasn't defined clearly to start with. I wrote down the deliverables and...
• Made the team accountable for delivering this (see: they agreed to deliver within the parameters). If they keep missing deadline after deadline with no consequence, then I found they didn't bother putting in the extra hours or effort to get it done on time. A due date or deadline isn't when something needs to be delivered, it's the point of time where consequences kick in if it's not delivered. Which one would a team pick to adhere to out of those two options?
• I kept breaking tasks down smaller and smaller, and the reporting periods smaller and smaller until they started being met regularly. At this point you can start increasing the responsibility again while keeping close tabs on it

Yes, it may come across as micromanagement. But if a team or person is incapable of delivering on time, or giving sensible estimates, or doesn't understand the impact of missing their deadlines, or taking responsibility for their tasks, then something needs to change to fix this.

To summarise, I feel like these teams need closer monitoring so you have the information you need to make your decisions and ensure project success. They sound like they're incapable of sharing this information with you willingly, so go get it!

Answer 5

Since Agile is not possible I would propose another approach.

1. You should try to decompose tasks into small chunks of work. Nearly 30-minutes - 1-hour size. Yes, it does require significant efforts investments from an architect or senior developers. And pay only for a finished task.

2. Try to build up continuous integration/continuous delivery automation and culture. Like in EOD all increments merged and deployed to production no matter what.

3. Then use EVM for forecasting, it is simply indispensable when dealing with fixed price. http://www.methodsandtools.com/archive/archive.php?id=61

It's a kind of marginal approach but works in a described environment.