projectified

Another Sprial

Frank Patrick says here that there are add-ons for Project that help model the uncertainty related to the number of spirals or iterations in a project. I have not looked at these add-ons but I'm sure that they do what he says they do.

He also says:

Although one aspect of the spiral is the unknown nature of how many times one goes around. That's what basic PM software does not handle so well.

My question is why should it 'handle' this up front? Sure you don't know how many times around the spiral you will go but you know you will go at least X times around. So you build your schedule around that number and then if you are pretty sure you will go around X+1 then you add that extra on the end. Then after you go a few times around you figure out that the real number will be more like X+3. So then you add those on to the end to make your model better.

Schedules are not deterministic so why should the model we build up front be anything more than our current best shot at the future?

Now that said I would love to see these add-ons and check out what they do to help this. But I do tend to concentrate on the core product. I have to since I cannot count on my customers using this add-on or that add-on. I CAN count on them using Project and Project Server. So I tend to try and find workarounds within that framework first before I look to 'custom' solutions. But I will take a look at some of these and try to report back on them with my thoughts.

Can Project "Do" Sprial Methodolgies?

Several years ago I heard someone say that Microsoft Project was outdated because it was only suitable for projects that used a so called “waterfall” scheduling methodology. I heard it again recently and was struck again at how silly this seems to me. Im not sure if this kind of thinking comes from the need to reject the old and embrace the new in the current software development business or if it has to do with the zealotry with which people embrace their favorite software development methodologies but it has to stop. In my opinion saying that Project (or for that matter Primavera, Niku, Artemis or any other scheduling software) cannot model a spiral or iterative development lifecycle is just being intellectually dishonest.

What is a ‘waterfall’ methodology? It is the term given to a lifecycle where all the design is done before any of the development starts and where all the development is done before any of the testing starts. It’s Gantt chart looks like a waterfall with each phase joined with a finish-to-start relationship.

What is a spiral or iterative methodology? It is a lifecycle where the design, develop, test phases are repeated several times before the end product is complete. There are several different flavors of this methodology. Practitioners of this methodology like to describe this visually with a spiral diagram where each phase repeats as the spiral goes in toward the center (or sometimes out).

Both of these methods are valid for different kinds of projects. Just like no one Task Type in Project is appropriate for ALL tasks in a project and no one kind of hammer is best for all kinds of construction different software development methodologies are appropriate for different kinds of projects. If you have all the requirements up front and they will stay static then a waterfall methodology is fine. However, if you do not have all the facts up front or they will change then a form of spiral development might be best.

Here is the fun part. What do you suppose that nice spiral diagram would look like if you unrolled it and laid it out across a timescale? A waterfall maybe? :-) Yes! It would look like a waterfall remarkably like the one for the waterfall methodology. It is just that this waterfall would have more phases. It would have several design phases, several develop phases and yes even several test phases and then it would have a final test phase at the end.

If you can lay it out on a timescale then you can model it in Project (or any other scheduling application). I think that it is often the case that people that are involved in something new or innovative can get a little carried away with the whole cool nature of being cutting edge. Don’t get me wrong. I think that many of the “new” methodologies offer some great benefits. But anytime you start the coolness of your thing is intoxicating to the point that you stop seeing the benefits of other things that are different from your thing then there is a problem.

In the end the 3rd design iteration of a spiral project or a “sprint” in a SCRUM project or the Testing Phase in a waterfall project all have some things in common: they all have a start and finish date, they all require work to complete and they all need resources to complete them. No matter how special you make the framework these things exist in they are still just tasks that need to be scheduled.