5

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?

  • do the consultants work only for you? do they work in house? – Ewan Apr 3 '17 at 4:49
  • 2
    Please stop calling people - resources. – Alexander Averchenko Apr 3 '17 at 8:27
  • @AlexanderAverchenko The PMBOK calls them resources. For example as a process - estimate activity resources, or also a part of human resource management. The lay person would call them labor resources. – Shawn Apr 3 '17 at 17:09
  • Relevant to the people vs. resources debate: pm.stackexchange.com/a/21278/25606 – Sarov Apr 7 '17 at 13:46
  • @Sarov Great read. I get where that thread is coming from in that each team member is not the same person to be easily replaced but from a standard definition a resource is "a supply of money, materials, staff, and other assets that can be drawn on by a person or organization in order to function effectively." Not to mention its the common PM language used but I understand both sides of it. – Shawn Apr 7 '17 at 18:17
3

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

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.

  • This would be great but I cannot control a change like that. That would have to come from the functional manager. – Shawn Apr 2 '17 at 19:41
1

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.

1

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!

  • This is a very practical solution. I think all of them are factors and very specifically that the problem sits with point #3. The problem is their manager is responsible for dealing out consequences and escalation channels respond slowly here; which makes your points #1 and #4 very valuable for how I will continue forward on this project. – Shawn Apr 7 '17 at 15:53
  • Good luck. When getting teams or staff to agree to their responsibilities and deliverables, again, make the agreement totally unambiguous. This serves at least two benefits: first, when someone makes a requirement super-clear, you realise how much attention they're paying to it, so you pay more attention too. The second benefit comes when they repeatedly miss deadlines: show them the agreement that was very clear and that they agreed to = no wiggle room. And then show upper management if nothing else works. It's a bit formal, but then, project success is the most important thing here. – dKen Apr 8 '17 at 3:35
0

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.

  • 1
    I agree with all of these items. We are far away from continuous integration from an enterprise standpoint, but perhaps I can get the EVM items on an agenda. – Shawn Apr 3 '17 at 17:14
  • Shawn, I can recommend you the consultant who can help with CI/CD it would be the best investment in your life. – Alexander Averchenko Apr 4 '17 at 6:02

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.