Project Management and Scheduling Techniques

Question

Hello,

I know this is probably the nth project management question. But am trying to move my team onto a more robust project management technique. Am wondering what is the best technique to use? I know that probably no technique is best, but which are the most popular techniques? Poker planning? Evidence Based Scheduling? COCOMO? Agile? Scrum? XP? Which one to use?

Also, suppose I use EBS, wouldn't it be too time consuming to break down every single activity into fine grained tasks? E.g. "Design" is a goal, what kind of fine-grained tasks will I have under it?

Is this is a waste of time i.e. dividing work into so many micro parts. Usually when I give my programmers a task, I follow up every week, and they complete quite a lot of the task assigned to them (the tasks are very broad e.g. X module). Is EBS worth it? Are there any white-papers on it so that I can implement it on my own? (instead of using Fogbugz)

Most of my projects are web-based projects.

Thank you for your time.

Answer 1

It's impossible to recommend a PM model without knowing:

• The size of your team
• What you produce
• The roles on your team
• How your timelines work
• What technologies you use (not critical, but helpful)

There is no one-size-fits-all PM model. You'll probably find that some are more adaptable than others. For example, agile project management works very well for projects that don't have to adhere to complex processes imposed by an organization.

Answer 2

Here is what I use. I use scrum to find out what people are doing, what they plan on doing, and where they are at with their projects. Everday I do a 15 minute meeting and I schedule it at 9am so everyone shows up to work on time. Its amazing how much work has gotten done since I implemented this strategy.

Also I use Source Safe to view the files people have been working on. If people are slacking off and lying it is very aparent in source safe. TFS offers some more advanced features in terms of reporting. I don't believe lines of code dictate how good a programmer is, but you should at least check in a few lines of code every day :D.

In terms of dividing labor, I let developers pick how they want to divy up the work. Some developers like workign with others, some do not. Your developer will know better than you how the work needs to be cut.

Answer 3

You are right, it is a complete waste of time to break tasks down into "micro parts". You hire experts that you shouldn't need to explain each key press to. Any task that is shorter than 4 hours is micro managing. Any longer than 5 days is probably a bit vague and will lead team members to plan to do it "next week".

Micromanaging is bad, but it's a good idea to make your tasks a bit more measurable than "design". This could be broken into "Complete initial design", "Peer Review", "Review by account manager", "Sign off by client". This way you can track where you are at as each of these tasks are binary.. ie: they are done or not done. Secondly this forms a check list of how you do things, otherwise for expediency you may skip the things you'd said you do and you know improves the product. Lastly by having concrete tasks you can measure you avoid being "90% done" on tasks for weeks.

I find the 4 hours to 5 days rule approach very useful. Also if you're interested in some more detail around task management see this post on the topic.

Answer 4

It seems as if you're mixing carrots and apples here: project estimation, planning and management models.

But the asnwer to your question "what would be a more robust project management technique for the team" is "any that you and your team understand well".

It is way more important that everyone understands the process used and is able to critically appraise it in a given context (what works and what doesn't) than picking and trying to use "a better model" without being able to judge it merits based on your circumstances.

Lets try re-phrasing the question from "what would be a more robust project management technique for the team" to "how we can manage our projects X, Y, Z in a more robust way". I suggest the following plan:

• Make an inventory (even if in your mind) of everyday events that cause delays, mistakes, uncertainty and lead to failed tasks, missed deadlines, low quality, scope creep, inflated budgets etc.

• Make habit of analysing them to understand the root cause. For example, Five Whys is an extreemly simple and effective technique for the root cause analysis.

• Then look for tools and techniques to address the root causes and not the other way around.

Answer 5

To gain the most benefit from project management processes, you first have to do an analysis of which one(s) would have the most positive impact. Putting in scheduling, work breakdown structures (WBS), etc. just because they're project management processes might end up hurting more then helping. Ask yourself: What is my/my-teams biggest pain points? Where do we often fall down? Focus on the real problem and not symptoms and then implement a solution. If you're missing schedules because you didn't identify all the tasks/components up front - then a work breakdown structure/process makes sense. If you're seeing a lot of quality issues in the delivery then look into test driven development...hope that helps (I call this Risk Focused Management)

Answer 6

if you want something simple to start with, you can use joels older method for project scheduling (the evidence based one is more mature software dev houses)

i have an adapted version which uses google to make it easier for a team-based environment

you can read more about it here: Project Schedules with Google Spreadsheets

--LM