« Iterative Design\Build Loops in the Configuration of Project Server: First Pass and Initial Thoughts | Main | When did "Resource" or "Coder" Become 4 Letter Words? »

Monday, January 30, 2006

Comments

Jeff,
You could certainly just have the backlog 'scheduled' to start well in the past or well in the future, knowing that most of your reporting will be for the near term. Those backlog tasks would then show up 'off scale'.

the approach I would likely favor though would be one where the backlog tasks were marked in some way with a custom field and then scheduled where they MIGHT be done based on current assumptions. If other work pushes them off that date then just move them. Instead of thinking of that work as unscheduled think of it as work that is scheduled but scheduled with low confidence. You put a backlog task for starting next week. Then you figure out that it will not happen then so you just move it out to the next slot when you would like it to happen. This is the same as any other task. You schedule it when you want\hope\need it to be done and if reality creeps in makes it clear that it will not happen next week you move it.

Just a thought.

Also, we can take this up via email if it would help. brian.kennemer@microsoft.com

So, given that, any recommendations on how to track a backlog in Project? Project historically doesn't handle unscheduled tasks well, so having a backlog and not scheduling start/end dates for tasks until they are loaded into a sprint seems to incompatible with Project's basic usage. Any pointers, tips, or suggestions for doing the practically in an enterprise are greatly appreciated!

I figured it was not just marketing but the marketing cynic in me always sees that as a possibility when I see something like your original post. Glad to hear it.

You are comparing the desktop client of Project to your web based tool that is designed specifically around a specific development process.

Project is designed to aid in the scheduling of work and the processes around resource usage and progress tracking. If you are in an organization that does not require things such as projected finish dates, costs, resource usage and loading across projects then no scheduling application is for you.

I disagree that managing iterations in Project is hard. All an iteration is is a miniature project. Analyze, design, build, test. Then do it again and again and again.

Now once you start bringing in things like time tracking then you are talking about Project Server. It has time tracking. It also has document management through WSS and a ton of other features.

No it does not have a built in concept of velocity but it could get added with a pretty small customization without much problem.

The thing is that MSFT has to design a product for the wider audience. This necesarily means that some users will see specific features missing (velocity, release management, etc). But it provides the features that the vast majority of users want and use on a daily basis and more importantly it provides a workable base upon which to add those extra, context specific features that only some users need.

Hi,

I am the guy who wrote that blog post about MS Project ;) No, this is not a marketing stuff. I do not use such dirty methods in product promotion, this is just my personal opinion.

Some responses. Yes, you can do waterfall with any tool, including TargetProcess, but it will be really hard. There is no connections between tasks in TP, there is no Gantt chart, there is no leveling. You will fail if you try to create whole plan upfront.

The same thing with MS Project. It is not easy to manage iterations in MS Project.
There is no product/release backlog. There is no integrated time tracking to measure actual work, there is no "true time remaining", There is no iteration velocity concept and so on.

So you are right, you can do any process in both tools, but don't forget about additional pain in both cases.

Maybe my wording is not perfect, but you've got the idea.

I will address more details in the next post.

Help is just an example.

I want to believe that. It seems that it would have to be that but my cynical nature with regard to marketing makes me sad. :-)

I poked around in thier online demo and it has some interesting things going on in there.

I hope they respond in some way. It would be an interesting conversation for sure.

Brian

Brian, Good backgroudn. My sense is the OP didn't think through the wording, espically since the PM community is hyper sensitive to unfounded claims of success or failure of any one product.

It'll be interesting to see if there is a response to your discussion. This is an example - IMO - of how little is actually known about managing projects and how much is focused on the latest gadget or process.

The comments to this entry are closed.