News of Project's Death with Regard to Software Projects Has Been Exaggerated. Again!

 So the guys over at Target Process just informed the world that Project is based on the waterfall process and is therefore unsuitable for use in managing a software project! LOL Wow that is news to me and the thousands of others that have used to manage iterative software development projects! :-)

I posted a comment on their post that talked about my disagreement and have had this response in draft form ever since and had forgotten about it until Glen posted on the subject. It was not until I read Glen’s post that I realized that Target Process markets a product that competes with Project! This certainly casts the post in a different light. When I first read it  I did so with the thought in mind that the writer was just not understanding how scheduling software really works or what the basis is for building and indeed using such software. But knowing that the poster works for a company that competes with Project it now just smacks of an intentional distortion of the facts with the end goal of boosting sales of their product. While this certainly may NOT be the case (I really want to believe that this was not the thrust of their post) it certainly starts to look that way.

Microsoft Project is not based on “Waterfall”
It just isn’t. Neither are the scheduling engine components of Primavera, Niku (sorry I meant CA), Artemis, Planview or any other major scheduling application that I have seen. You can MAKE them do waterfall. You can make any application do waterfall. I can make Basecamp do waterfall and you could likely make Target Process’s tool do waterfall too no mater how centered it’s design is on Agile. Hell, I can make 3x5 cards like the ones used in XP\Scrum do waterfall!! Waterfall is a process for planning a project. It is not tool specific. It is project environment specific. Waterfall can work as a method for scheduling software projects. Not many in my opinion but they are out there. The method you use to plan your work (be it a software project or the creation of marketing materials or the building of a dam) should be context sensitive. If you have the requirements up front and they will not likely change through the course of the project then waterfall might be the thing. In a case like this an iterative approach might add loops that are a waste of time given the locked down nature of the requirements. If you are building something there the requirements are fuzzy and likely to change over time then the obvious choice is a method that is iterative at it’s core (whichever method that might be for your case.)

As I mentioned in my comment on the original post I agree that the Help file that comes with Project should address other planning processes. In fact in my Outlook outbox (I’m on a plane right now without Internet access) there is currently an email to several people on the Project development team suggesting just that. However, the mere fact that the Help only mentions waterfall type methods does not mean it is based on waterfall nor does it mean that you cannot use Project to do iterative projects. To suggest otherwise is like saying you cannot toast a bagel in your new toaster because the instructions only mention bread and English muffins. :-)

Project IS “Connected”
These comments really just seem like marketing spin to me and have been covered in my comments on the original post and in Glen’s post. Suffice to say that Project Server addresses these comments have little to do with the suitability of Project as a scheduling engine for software projects. A deck of 3x5 cards used to organize SCRUM or XP tasks are not ‘connected’ either since only one person can ‘hold’ them at a time so give me a break. :-)

 

Comments

[Brian Kennemer]

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

[Jeff]

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!

[Brian Kennemer]

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.

[Michael]

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.

[Brian Kennemer]

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

[Glen B. Alleman]

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.