[QUOTE=platosrevenge]
The problem is the team does not know what they should be doing without constant interaction with me, which causes overhead and wasted time.
The result is people either come to me to find out what to do, or they just spend excessive amounts of time on particular parts of a project and kill the budget.
[/QUOTE]
Based on this, the first thing that comes to mind is that the tasks your assigning are NOT well defined. There is too much not defined, so your developers come to you for the rest of the information. Similarly, if they are spending excessive amounts of time on only parts, then the “completion criteria” is also not well defined.
As smart as developers are, with a big project made up of lots of smaller tasks, having a clear understanding of each task (which includes knowing when it is complete) is KEY. It will SAVE YOU TIME IN THE LONG RUN to take the time to define/describe/brain dump all that you can about the individual tasks. Just because you have a good sense of what the tasks are (and it can be assumed this is true since they all go to you to get the answers), doesn’t mean the developers can “infer” the same level of detail. Spell it out for them.
Next, “assigning” durations for the tasks to be completed won’t really work unless you get some buy-in from the developers. Pick some durations, and then ask them “do you think this task can be completed in this time ?” If they don’t agree, you may need to negotiate. Or you may have to acknowledge that they don’t think it is realistic. But without some level of buy-in, 1) the developers won’t have much “incentive” to actually meet the schedule, and 2) you won’t have any recourse when they slip (“why didn’t you complete this task in this duration ?”).
As to statusing, daily seems to “micro”. If tasks typically take more than 1 day, then most of the status you take on a daily check will be “in progress” - not of much use, and daily status just becomes annoying. Depending on the length of the tasks, usually once a week should be sufficient. This isn’t always true, but is generally the case.
The key to statusing tasks that are slipping is not “how much is complete ?”, but rather “how much longer do you believe it will take ?” If you ask “how much is complete ?” you open yourself up to replies like “90%” or “95%” - close, but no indication of how much longer. If you ask “how much longer ?”, again, you are getting some commitment/buy-in from the developer on completing the task within a given timeframe. The difference is subtle, but important.
Developers are intelligent, creative people. But are also notorious for being terrible estimators - in both extremes, but typically in underestimating (tasks always seem easier than they turn out to be). It may take years to “calibrate” the various developers, if it is even possible. But you’ll soon get a feel for the people who are grossly off from their estimates. And you can account for that in your schedule.
Developers also need to stay on track - not get caught up in one aspect and lose sight of the whole task. Instead of the daily group meeting, I would recommend “making the rounds”. Stop by each developer (or just the ones who are prone to get sidetracked), and check in on them. Ask them what they’re working on, and make sure they are staying focused. Importantly, if you get a sense they are flailing and stuck on some issue, be thinking of ways to help them (have another developer work with them, etc.). Developers are also notorious for being convinced they can solve any problem - even if it takes them years
Lastly, as you make the rounds, be sure to see if there is anything the develop needs (waiting on stuff from another developer, more information, etc.) that is holding them up. Developers may not let you know of any roadblocks that are holding them up.
Hope this helps. If you want to e-mail or PM me, feel free. (Yes, I was/am a developer. And then did project management)